اللحظة التي توقّفت فيها عن بناء الأدوات
بدأ SnapLedger كأداة لتتبّع المصروفات. ثم علّمتني مستندات أليكس — وثلاثون تطبيقًا لدى صديقة محامية — أن المشكلة الحقيقية ليست في مزيد من الأدوات، بل في ربط المعلومات.
حين بدأت أبني SnapLedger، كان هدفي في الواقع بسيطًا جدًا.
أردت حلّ مشكلات الإدارة المالية—تنظيم الإيصالات، وإدارة المطالبات المالية، وفي نهاية المطاف مساعدة المستخدمين على إعداد إقرارات ضريبة القيمة المضافة.
ولفترة طويلة، كان وصف موقعنا لمحركات البحث ببساطة:
"تتبّع للمصروفات مدعوم بالذكاء الاصطناعي."
في ذلك الوقت، كان هذا بالضبط ما ظننت أن SnapLedger هو.
ثم غيّر أليكس رأيي من جديد.
مجلّد مليء بالخيوط
كما ذكرت في مدونتي السابقة، صار أليكس أول شخص أراد فعلاً استخدام SnapLedger لعمله. ولكي يساعدني على فهم سير عمله، شاركني مجلّدًا كاملاً يحوي سنوات من مستندات العمل.
وبين آلاف الملفات، لاحظت شيئًا مثيرًا للاهتمام.
كانت هناك قسائم رواتب أُنشئت يدويًا. وكانت هناك فواتير أُعدّت يدويًا لعملائه.
كان ردّ فعلي الأول بسيطًا: "حسنًا... يمكنني أن أُسهّل حياة أليكس."
فبنيت صندوق أدوات صغيرًا للموارد البشرية. كان بإمكانه إلحاق الموظفين، وحفظ سجلاتهم، وتشغيل الرواتب.
والأهم أنني أردت للبرنامج أن يقوم بمعظم العمل تلقائيًا. سيتعرّف SnapLedger على قسائم الرواتب التي أنشأها أليكس يدويًا في الماضي، ويقرأ عقود العمل التي يرفعها، ويحدّد بيانات الموظفين، ويعيد بناء تاريخ الرواتب، ويُنشئ دليل موظفين تلقائيًا.
فبدلاً من إعادة إنشاء قسائم الرواتب كل شهر، ينقر أليكس ببساطة على تشغيل الرواتب، ويراجع النتائج، ويرسل الدفعة. لا مزيد من إنشاء المستندات يدويًا.
ظننت أنني أبني وحدة موارد بشرية.
ثم حدث شيء مثير للاهتمام
بدأ المستخدمون يرفعون مزيدًا من المستندات المتعلقة بالموظفين. مستندات تأشيرات. عقود عمل. وثائق تأمين. سجلات طبية.
وفجأة صار جليًا أن كل هذه المستندات تخصّ الموظف نفسه.
فلماذا ينظّمها المستخدمون يدويًا؟ ينبغي لـ SnapLedger أن يفهم هذه العلاقة تلقائيًا.
وبمجرد أن يرتبط كل شيء، تظهر إمكانات جديدة كليًا. فبدلاً من مجرد تخزين المستندات، يستطيع النظام أن يذكّرك بأن تأمين موظف على وشك الانتهاء، أو يُنبّهك عند اقتراب موعد تجديد تأشيرة، أو يحذّرك من غياب مستند مهم.
يبدأ البرنامج في فهم عملك بدلاً من مجرد تخزين ملفاتك.
وحدث الأمر نفسه مع الفوترة. في البداية بنيت مولّد فواتير بسيطًا لأن أليكس كان يُنشئ فواتيره يدويًا أيضًا. لكن ما إن وُجدت الفواتير حتى ارتبطت طبيعيًا بالعملاء. والعملاء ارتبطوا بالمدفوعات. والمدفوعات ارتبطت بكشوف الحسابات البنكية.
وسرعان ما احتجنا إلى دليل عملاء. ثم دليل موردين. وأوامر شراء. وإدارة فواتير.
ومن دون تخطيط واعٍ، تطوّر SnapLedger تدريجيًا إلى شيء أكبر بكثير—منصة تشغيل أعمال متكاملة.
الإدراك
كانت تلك اللحظة التي أدركت فيها أمرًا مهمًا.
المستقبل ليس في بناء مزيد من الأدوات، بل في ربط المعلومات.
مستندات العمل ليست ملفات معزولة. كل إيصال ينتمي إلى عملية شراء. وكل عملية شراء تنتمي إلى مورّد. وكل فاتورة تنتمي إلى عميل. وكل راتب ينتمي إلى موظف. وكل معاملة بنكية تنتمي إلى شيء آخر موجود أصلاً داخل عملك.
المحاسبة ليست سوى مثال واحد على هذا العالم المترابط.
لاحقًا، شاركت هذه الفكرة مع صديقة في الولايات المتحدة تدير مكتبها القانوني الخاص. بعد أن أصغت إلى القصة، ابتسمت وقالت:
هذه مشكلتي بالضبط. أستخدم أكثر من ثلاثين برنامجًا مختلفًا، ولا يتحدّث أيٌّ منها إلى الآخر. لو استطاع نظام واحد بسيط أن يدير هذا كله لي، لدفعت مقابله بكل سرور.
جعلني ذلك الحديث أدرك أن هذه المشكلة ليست حكرًا على المحاسبة. إنها عامّة.
أعمالنا—بل وحتى حياتنا—مليئة بالعمل الإداري. مستندات. نماذج. عقود. إيصالات. فواتير. تأمينات. رواتب. تأشيرات. كشوف حسابات بنكية.
كلٌّ منها كخيط يقود إلى متاهة هائلة. ويُتوقع منّا كبشر أن نتذكّر كيف يرتبط كل خيط بكل خيط آخر.
لكن لماذا يجب علينا ذلك؟
لا ينبغي للذكاء الاصطناعي أن يكتفي بتوليد نصوص أو تصنيف إيصالات. عليه أن يفهم كيف ترتبط المعلومات. وحالما يفهم تلك العلاقات، يبدأ العمل الإداري في الاختفاء بشكل شبه تلقائي.
الرؤية اليوم
هذه هي رؤية SnapLedger اليوم.
لم نعد نحاول بناء برنامج محاسبة أفضل. بل نحاول بناء نظام يفهم عملك جيدًا بما يكفي ليرفع عنك العمل الإداري بهدوء، لتُنفق وقتك في خلق قيمة بدلاً من مطاردة الأوراق.
وأظن أن هذه مشكلة أكثر إثارة للاهتمام كي نحلّها.
المستقبل ليس في بناء مزيد من الأدوات، بل في ربط المعلومات.
ما الخيوط في عملك التي لا يتحدّث بعضها إلى بعض أبدًا؟
درس اليوم: مستقبل البرمجيات ليس مزيدًا من الأدوات، بل فهم كيف يرتبط كل شيء بكل شيء.