أودو مقابل Tally: التوقيت الصحيح للارتقاء.

المشكلة ليست في Tally. ففي مسك الدفاتر البحت — إدخال سريع لسندات القيد، ودفاتر أستاذ متوازنة، وميزان مراجعة يمكنك الوثوق به — لا يزال من أفضل الأدوات في المنطقة، وقد نال هذه السمعة بشقّ الأنفس، على مدى عقود، بين أيدي المحاسبين. إذا كانت أعمالك في جوهرها مسألة مسك دفاتر، فإن Tally يحلها جيداً، ولا يوجد سبب وجيه للمساس به.

يظهر سقف Tally في اللحظة التي تتجاوز فيها الشركة كونها مسألة محاسبية فحسب، لتصبح مسألة عمليات تشغيلية. فقد بُني Tally لتسجيل ما حدث بالفعل، ولم يُبنَ قط لإدارة ما يحدث بعد ذلك: الموافقات، وحركات المخزون، وتسليم العمل بين الفروع، والرؤية الشاملة التي تحتاجها الشركة النامية. ونادراً ما تلاحظ الشركات التي تتجاوز Tally لحظة إخفاق واحدة بعينها، بل تلاحظ تراكماً بطيئاً لجداول البيانات ومحادثات واتساب التي تسدّ مكان نظام لم يُبنَ قط. هذا النمط يستحق أن نسمّيه بصراحة، وكذلك ما يتغير فعلاً إذا قررت الانتقال.

ما يُتقنه Tally ببراعة — وأين يتوقف

لنُعطِ Tally حقّه. فإدخال سندات القيد فيه سريع فعلاً، وأسرع من معظم أنظمة تخطيط موارد المؤسسات (ERP) لمن تدرّب عليه، وكل محاسب في الإمارات وباكستان استخدمه أو استخدم ما يشبهه. وهو يعمل دون فريق خوادم، ودون اتصال بالإنترنت، ويُنتج دفاتر أستاذ وموازين مراجعة تتطابق بدقة. كما أن تقارير ضريبة القيمة المضافة وضريبة المبيعات الأساسية مدمجة فيه وموثوقة. وبالنسبة إلى شركة يبدأ تعقيدها الحقيقي وينتهي عند مسك الدفاتر، فهذا حل متكامل، والانتقال عنه سيكون حلاً يبحث عن مشكلة.

هذا السقف بنيوي، وليس إعداداً نسي أحدهم تفعيله. يتعامل Tally مع المخزون كدفتر لحركات المخزون، لا كسير عمل؛ فهو لا يحوّل أمر البيع إلى عملية تسليم، ولا أمر الشراء إلى استلام بضاعة، من تلقاء نفسه. ولا يتضمن مسارات موافقات مدمجة، فتنتقل الاعتمادات إلى البريد الإلكتروني أو الورق أو واتساب. والصلاحيات فيه سطحية، لذا يصعب أن تفرض بأي قدر من الثقة منع أحدهم من تعديل سند قيد مُرحَّل أو الاطلاع على أرقام فرع آخر. ولا يوجد فيه نظام لإدارة علاقات العملاء (CRM)، ولا تصنيع، ولا بوابة للعملاء، ولا توحيد فوري لحسابات الفروع المتعددة — لا لأن Tally يؤدي هذه المهام بشكل سيئ، بل لأنه لم يُبنَ لأدائها أصلاً.

علامات تدل على أنك تجاوزته

• نتائج الجرد الفعلي لا تتطابق أبداً تطابقاً تاماً مع ما يُظهره Tally، وكل جرد يتحول إلى تحقيق بدلاً من أن يكون إجراءً شكلياً.
• تتم الموافقة على المشتريات أو الخصومات أو المدفوعات عبر لقطات شاشة على واتساب، دون أي سجل يوضح من وافق فعلاً، أو متى.
• إقفال نهاية الشهر يعني أن يدمج أحدهم يدوياً جداول بيانات خمسة أو ستة فروع في رقم واحد، على أمل ألا يكون شيء قد احتُسب مرتين.
• معرفة ما حدث اليوم في فرع آخر تتطلب مكالمة هاتفية لا نظرة إلى الشاشة، والإجابة تتوقف على من يرد على الهاتف.
• يتطلب البيع والتسليم والفوترة إعادة إدخال البيانات ثلاث مرات منفصلة بدلاً من مسار واحد متصل، والفجوات بينها هي حيث تكمن الأخطاء.
• يتعلم الموظفون الجدد كيف تسير الأعمال فعلاً من زميل ومن مجلد مشترك لجداول البيانات، لأن الإجراءات الحقيقية لم تكن موجودة في النظام قط.
• يقترب موعد نهائي للامتثال — الفوترة الإلكترونية الإلزامية في الإمارات أو الفوترة الرقمية لهيئة الإيرادات الفيدرالية الباكستانية (FBR) — وليس أمام Tally طريق حقيقي إلى أيٍّ منهما دون إضافة ملحقة لا يريد أحد تحمّل مسؤوليتها.
• بدأت تتساءل بصوت مسموع عمّا إذا كانت الشركة تحتاج إلى نظام لإدارة علاقات العملاء (CRM)، أو وحدة تصنيع، أو بوابة للعملاء — وهذا يعني عادةً أن جزءاً منك يعرف الإجابة مسبقاً.

ما الذي يتغير عند الانتقال إلى أودو

• نظام واحد، لا ثلاثة أنظمة. تُحدَّث المبيعات والمشتريات والمخزون ودفتر الأستاذ جميعها من المعاملة نفسها، فلا يضطر أحد إلى إعادة كتابة عملية بيع في جدول بيانات لمجرد معرفة المخزون الفعلي.
• مخزون لحظي. ما يُظهره النظام على الرف هو ما يوجد فعلاً على الرف، لأن كل حركة تُحدّثه تلقائياً.
• صلاحيات وسجل تدقيق. من وافق على ماذا، ومتى، وما الذي غيّره — كل ذلك ظاهر في النظام، لا يُستعاد من الذاكرة.
• بوابات إلكترونية. يطّلع العملاء والموردون على طلباتهم وفواتيرهم وأرصدتهم بأنفسهم، دون الاتصال بمكتبك للسؤال.
• فوترة جاهزة للامتثال. مصممة للفوترة الإلكترونية الإلزامية في الإمارات وللفوترة الرقمية لهيئة الإيرادات الفيدرالية الباكستانية (FBR)، لا كإضافة تُلحق لاحقاً.

كيف يتم الترحيل فعلياً

الانتقال من Tally لا يعني فقدان السجل التاريخي، ولا يعني إعادة إدخال معاملات عشر سنوات يدوياً؛ فلا أحد يملك ميزانية لذلك، ولا ينبغي لأي شريك صادق أن يَعِد به. ما يُنقل فعلياً هو البيانات الرئيسية للشركة — العملاء، والموردون، والأصناف — وأرصدتها الافتتاحية، وفواتيرها المفتوحة غير المسددة. أما المعاملات التاريخية المُقفلة فتبقى عادةً في مكانها تماماً، مؤرشفةً في Tally للرجوع إليها ولأغراض التدقيق. هذه ممارسة معتادة، لا طريق مختصر، وأي خطة تَعِد بإعادة إنشاء كل سند قيد تاريخي داخل أودو إما أنها مكلفة جداً، وإما أنها لا تصارحك بالحقيقة كاملة.

العمل الحقيقي هو بناء ما لم يمتلكه Tally قط: مسارات الموافقات، ومنطق المخزون، وهيكل الصلاحيات، والبوابة التي سيستخدمها العملاء فعلاً. وفي نطاق نموذجي لشركة صغيرة أو متوسطة، يستغرق ذلك من أربعة إلى ثمانية أسابيع من انطلاق المشروع حتى التشغيل الفعلي، بما يتماشى مع الجداول الزمنية الموضحة في دليلنا لتطبيق أودو. وقبل الانتقال النهائي، نُجري شهراً من التشغيل المتوازي — تُدخَل فيه المعاملات الحقيقية في النظامين جنباً إلى جنب — كي تظهر أي فجوة بينما لا يزال Tally متاحاً للمقارنة، لا بعد إيقافه.

هذا هو صميم عمل فريق الترحيل والترقية لدينا، سواء كان الانتقال من Tally، أو من نظام آخر لتخطيط موارد المؤسسات (ERP)، أو من كومة من جداول البيانات — فالمنهجية الموضحة أعلاه هي نفسها التي نتبعها في كل مرة.

الطريقة الآمنة للانتقال

استبدال النظام الذي تقوم عليه حساباتك ليس قراراً يُتخذ عن ثقة عمياء، وعليك أن تحذر من أي شريك يطلب منك ذلك. اطلب أن ترى عملاءك أنت، وأصنافك أنت، ومسار الموافقات الخاص بك، تعمل داخل نظام حقيقي — لا عرضاً تجريبياً عاماً يعمل على بيانات غيرك.

وهذا بالضبط ما نفعله في كل مشروع تطبيق أودو في Knova: ترى بياناتك تعمل في النظام قبل أن تدفع أي رسوم، وإذا فاتنا موعد التشغيل الفعلي الذي اتفقنا عليه، تنسحب دون أن تدين لنا بشيء. ينبغي أن يكون الارتقاء من Tally مصدر ارتياح لا مخاطرة — وهذا الضمان هو ما يجعله كذلك.