من 5 موظفين إلى 500: متى تضيف كل نظام؟

في المقال الأول من السلسلة كتبنا الحد الأدنى من الأنظمة لكل قسم، ومعها في كل جدول عمود صغير اسمه «متى»، وهذا العمود هو موضوع هذا المقال، لأن أغلب الأخطاء في أنظمة الشركات ليست في اختيار النظام الخطأ، وإنما في اختيار النظام الصحيح في الوقت الخطأ. فالشركة التي تشتري نظام تخطيط موارد المؤسسة ERP وهي ثمانية أشخاص تقضي سنتها الأولى في إعداده بدل البيع، والشركة التي ما زالت تدير الإجازات في Excel وهي ثلاثمئة موظف تدفع ثمن ذلك كل يوم في موافقات ضائعة وحسابات لم تغلق.

المواضيع في السلسلة:

1. ما الأنظمة التي يحتاجها كل قسم في مؤسستك كحد أدنى؟
2. من 5 موظفين إلى 500: متى تضيف كل نظام؟ (الموضوع الحالي)
3. الأنظمة التي تحتاجها الجامعة: من القبول إلى التخرج.

وسوف نناقش في هذا المقال ما يلي:

• لماذا نرتب الأنظمة على مراحل، وما الخطأ في الشراء المبكر والشراء المتأخر.
• المراحل الأربع: اليوم الأول، ثم من 10 إلى 20 موظفاً، ثم قرابة 50، ثم 200 وما بعدها.
• العلامات التي تخبرك أن وقت النظام التالي قد جاء.
• الأنماط الخاطئة التي تتكرر في الشركات.
• تكلفة الاشتراكات لكل مرحلة كمثال توضيحي بأسعار مؤرخة.
• تجربة عملية: سكربت Python في Container يحول مصفوفة الأقسام والمراحل إلى جداول وقائمة تحقق، ويكشف النظام الذي جاء قبل ما يعتمد عليه.

وإذا كانت شركتك ناشئة تقنية وتريد خطة الأدوات مفتوحة المصدر لفريق الهندسة نفسه فقد كتبناها في المصادر المفتوحة في الشركة الناشئة وخارطة CTO لشركة SaaS ناشئة، وأما هذا المقال فيغطي أنظمة كل الأقسام وليس الفريق التقني فقط.

لماذا نضيف الأنظمة على مراحل؟

كل نظام جديد له تكلفة لا تظهر في فاتورة الاشتراك، فهناك من يعده، ومن يدرب الموظفين عليه، ومن يربطه بالدخول الموحد SSO، ومن يتابع تحديثاته ونسخه الاحتياطية، ولذلك فإن للخطأ في التوقيت اتجاهين:

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

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

والصورة التالية تبين المراحل الأربع والأنظمة التي تضاف في كل مرحلة:

والأنظمة في الصورة وفي جداول المراحل التالية هي نفسها صفوف ملف البيانات الذي نستخدمه في التجربة العملية آخر المقال، مكتوبة بالعربية، وقد دمجنا في الصورة صفين أو ثلاثة لتتسع.

المرحلة الأولى: اليوم الأول، من 1 إلى 9 أشخاص

في هذه المرحلة لا يوجد أقسام بعد، فالمؤسس يبيع ويوظف ويدفع، ولذلك فالمطلوب هو الأساس الذي يصعب تغييره لاحقاً، وما تطلبه الجهات الرسمية من الشهر الأول:

لاحظ ما ليس في القائمة، فلا يوجد نظام موارد بشرية ولا CRM ولا نظام تذاكر، والسبب أن ثمانية أشخاص يعرفون بعضهم، والجدول المشترك يكفيهم إذا كان له مالك واحد. ولاحظ أن الدخول الموحد SSO لم يأت بعد كنظام مستقل، وإنما الدليل الموجود في حزمة البريد، وهذا يكفي ما دام عدد التطبيقات قليلاً.

المرحلة الثانية: من 10 إلى 20 شخصاً

هنا يظهر أول مدير لا يعرف كل الموظفين شخصياً، ويظهر أول موظف يغادر، وتبدأ الأقسام في التشكل، فتظهر الأنظمة التي تحمي السجلين الرئيسيين، الموظف والعميل:

وأهم صفين في الجدول هما الدخول الموحد ونظام ال HRIS، لأن كل نظام يضاف بعدهما يأخذ حساباته من الأول وموظفيه من الثاني، وإذا تأخرا فكل نظام يضاف قبلهما سيحتاج إعادة ربط لاحقاً.

المرحلة الثالثة: قرابة 50 شخصاً

عند الخمسين تصبح الأقسام حقيقية ولكل منها مدير وميزانية، ويظهر قسم تقنية معلومات ولو بشخص واحد، وتظهر الحاجة إلى أن ترى الإدارة أرقام الشركة دون أن تسأل كل قسم:

ولاحظ أن نصف هذه الأنظمة لتقنية المعلومات والمالية، وهذا طبيعي، لأن هذه هي المرحلة التي يتحول فيها «الشخص الذي يفهم في الكمبيوتر» إلى قسم، وقد كتبنا شكل هذا القسم في فريق الدعم الفني.

المرحلة الرابعة: 200 شخص وما بعدها

بعد المئتين تصبح المشكلة هي التنسيق بين الأنظمة وليس غيابها، وتظهر المراجعات الخارجية، مثل المراجع المالي ومراجعة الأمن السيبراني وعملاء يطلبون شهادات، ولذلك فأنظمة هذه المرحلة أغلبها للسجل والمراجعة:

ومن 200 إلى 500 لا تظهر أنظمة جديدة كثيرة، وإنما يتغير شكل الأنظمة نفسها، فيحتاج الدخول الموحد إلى سياسات وصول مشروط، ويحتاج نظام التذاكر إلى فرق ومستويات، وتحتاج كل منظومة إلى مالك متفرغ، وهذا هو الوقت الذي تبدأ فيه إدارة محفظة التطبيقات كما في خريطة القدرات.

علامات أن وقت النظام التالي قد جاء

العلامات في الجداول السابقة تتكرر بأشكال مختلفة، ويمكن جمعها في خمس علامات عامة، فإذا رأيت واحدة منها في أي قسم فابحث عن النظام الذي ينقصه:

• سؤال «من وافق؟» بلا جواب: أي أن هناك موافقة تتم بالكلام أو الرسائل، فتحتاج نموذجاً بسير موافقات وسجل.
• العمل نفسه يتم مرتين: مثل عميل رد عليه موظفان، أو بيانات تنسخ من نظام إلى آخر باليد.
• معرفة في رأس شخص واحد: إذا أخذ إجازة توقف الإجراء، فتحتاج قاعدة معرفة أو نظاماً يحفظ الحالة.
• رقمان مختلفان للشيء نفسه: فتحتاج مصدراً واحداً للسجل وتقارير تقرأ منه.
• جهة خارجية تطلب سجلاً: هيئة رسمية أو مراجع أو عميل كبير، وهنا لا خيار في التوقيت.

أنماط خاطئة تتكرر

هذه الأنماط نراها في الشركات الصغيرة والكبيرة، وكل واحد منها له سبب منطقي في وقته ولكنه يكلف لاحقاً:

• ERP عند ثمانية أشخاص: المؤسس يريد نظاماً «يكفي للمستقبل»، فيقضي الفريق أشهراً في إعداد وحدات لا يحتاجها، والأنسب برنامج محاسبة متوافق الآن، وال ERP عندما تظهر علامته.
• الجداول عند ثلاثمئة موظف: الجدول الذي نجح في البداية يبقى لأن أحداً لا يملك وقت النقل، حتى يصبح فيه آلاف الصفوف بلا صلاحيات ولا سجل تعديل.
• أداة لكل فريق: فريق على Trello وفريق على Jira وثالث على Notion، فلا ترى الإدارة صورة واحدة، ويحتاج الموظف المنتقل إلى تعلم أداة جديدة.
• الخطة الأعلى من البداية: الدفع على ميزات المؤسسات الكبيرة لعشرة مستخدمين، والأنسب أن تبدأ بخطة أصغر بشرط أن تدعم التصدير، ثم ترفع الخطة عندما تحتاج الميزة.
• الخطة الأصغر إلى الأبد: عكس السابق، أي البقاء على خطة بدون دخول موحد ولا سجل تدقيق بعد أن تجاوزت الشركة الخمسين.
• استضافة كل شيء ذاتياً بلا مسؤول تشغيل: عشرون خدمة على سيرفر واحد لا يعرف طريقة استعادتها إلا شخص واحد، وقد شرحنا متى تستضيف ومتى تترك في قواعد القرار.

كم تكلف الاشتراكات في كل مرحلة؟ مثال توضيحي

أغلب الأنظمة السحابية تسعر لكل مستخدم شهرياً Per Seat، ولذلك تكبر الفاتورة مع كل موظف جديد، وقد راجعنا أسعار ثلاثة أمثلة من صفحات مزوديها في 14 أكتوبر 2026، وهي أمثلة للتوضيح وليست توصية:

وأما باقي الأنظمة فأسعارها تختلف كثيراً بحسب الخطة وعدد المستخدمين والتفاوض، ولذلك وضعناها في ملف التجربة كافتراضات واضحة يستبدلها القارئ بعروض الأسعار التي تصله، والسكربت يفصل في المخرج بين الأسعار التي تحققنا منها والأسعار المفترضة. والنتيجة في قسم الميزانية من التجربة أدناه.

تجربة عملية: من مصفوفة الأقسام إلى جداول وقائمة تحقق

الجداول السابقة كتبناها من ملف بيانات واحد، وهذا الملف هو الذي ننصحك أن تحتفظ به لمؤسستك بدل جداول متفرقة، والسبب أن الملف يمكن مراجعته وتعديله، والسكربت يتحقق منه في كل مرة ويخرج منه الجداول وقائمة التحقق والميزانية. والتجربة لا تحتاج أكثر من Python بمكتبتها القياسية، وسوف نشغلها في Container حتى لا نثبت شيئاً على الجهاز.

ملف البيانات

الملف org-systems.json فيه المراحل وعدد الموظفين التقريبي في كل منها، والأسعار، ثم صف لكل نظام، والصفوف التالية أربعة صفوف اخترناها من الملف، كل صف كما هو:

{ "id": "sso", "dept": "IT", "system": "SSO for every app", "col": "S2", "needs": ["directory"], "signal": "more than 5 apps or the first leaver" },
{ "id": "hris", "dept": "HR", "system": "HRIS (employee record)", "col": "S2", "needs": ["payroll"], "seat": "hris", "signal": "leave requests by email" },
{ "id": "jml", "dept": "HR", "system": "Joiner-mover-leaver flow", "col": "S2", "needs": ["hris", "sso"], "signal": "an account left open after a leaver" },
{ "id": "ats", "dept": "HR", "system": "Recruitment (ATS)", "col": "S3", "needs": ["hris"], "signal": "5+ open roles at once" },

في الصفوف أعلاه لاحظ التالي:

• الحقل col هو المرحلة، وsignal هو العلامة التي تخبرك أن وقت النظام قد جاء.
• الحقل needs هو أهم حقل في الملف، لأنه يقول إن النظام يعتمد على نظام آخر، فإجراء خروج الموظف لا معنى له قبل نظام ال HRIS والدخول الموحد، لأنه يقرأ من الأول ويغلق الحسابات في الثاني.
• الحقل seat يربط النظام بسعر لكل مستخدم في قسم الأسعار من الملف، وبعض الأسعار لها حقل share، أي أنها تطبق على نسبة من الموظفين فقط، مثل مستخدمي ال CRM.

السكربت

السكربت matrix.py يقرأ الملف ويتحقق من الاعتماديات أولاً، فإذا وجد نظاماً جاء في مرحلة أبكر من نظام يعتمد عليه توقف وطبع الخطأ، وإلا طبع أربعة أقسام:

"""Turn a department x stage matrix (JSON) into tables, a checklist and a seat budget.

Standard library only. Run in a container:
  docker run --rm --name lab-org-matrix -v "$PWD:/lab:ro" -w /lab python:3.13.16-slim python matrix.py org-systems.json

Data file: columns (ordered stages), rows (one system each: id, dept, system, col,
needs = ids that must exist first, signal = when you know you need it), and
optionally headcount per column and per-seat prices.
"""
import json
import sys
from collections import defaultdict


def load(path):
    with open(path, encoding="utf-8") as f:
        return json.load(f)


def validate(d):
    # A system must not come before what it depends on (e.g. a leaver flow before SSO).
    cols = [c["id"] for c in d["columns"]]
    pos = {c: i for i, c in enumerate(cols)}
    rows = {r["id"]: r for r in d["rows"]}
    problems = []
    for r in d["rows"]:
        if r["col"] not in pos:
            problems.append(f"{r['id']}: unknown column {r['col']}")
            continue
        for n in r.get("needs", []):
            if n not in rows:
                problems.append(f"{r['id']}: needs unknown system '{n}'")
            elif pos[rows[n]["col"]] > pos[r["col"]]:
                problems.append(f"{r['id']} ({r['col']}) needs {n}, which only comes in {rows[n]['col']}")
    return problems


def by_column(d):
    print("== 1. Systems added at each stage")
    total = 0
    for c in d["columns"]:
        rows = [r for r in d["rows"] if r["col"] == c["id"]]
        total += len(rows)
        print(f"-- {c['id']} {c['name']}: +{len(rows)} (total {total})")
        for r in sorted(rows, key=lambda r: r["dept"]):
            print(f"   {r['dept']:<16} {r['system']}")


def matrix(d):
    print("\n== 2. Department x stage (number of systems added)")
    cols = [c["id"] for c in d["columns"]]
    count = defaultdict(int)
    depts = []
    for r in d["rows"]:
        if r["dept"] not in depts:
            depts.append(r["dept"])
        count[(r["dept"], r["col"])] += 1
    print(f"{'department':<16}" + "".join(f"{c:>5}" for c in cols) + "  total")
    for dep in depts:
        cells = [count[(dep, c)] for c in cols]
        print(f"{dep:<16}" + "".join(f"{(n or '.'):>5}" for n in cells) + f"{sum(cells):>7}")
    print(f"{'all':<16}" + "".join(f"{sum(count[(dep, c)] for dep in depts):>5}" for c in cols) + f"{len(d['rows']):>7}")


def checklist(d):
    print("\n== 3. Checklist (you need it when...)")
    for c in d["columns"]:
        print(f"-- {c['name']}")
        for r in [r for r in d["rows"] if r["col"] == c["id"]]:
            print(f"[ ] {r['system']}: {r['signal']}")


def budget(d):
    if "prices" not in d:
        return
    print("\n== 4. Per-seat subscriptions per month, USD (illustrative)")
    prices, cols = d["prices"], [c["id"] for c in d["columns"]]
    print(f"{'stage':<6}{'people':>7}{'verified':>10}{'assumed':>10}{'total':>9}{'per person':>12}")
    for i, c in enumerate(cols):
        people = d["headcount"][c]
        live = [r for r in d["rows"] if cols.index(r["col"]) <= i and "seat" in r]
        sums = {"verified": 0.0, "assumed": 0.0}
        for r in live:
            p = prices[r["seat"]]
            seats = max(1, round(people * p.get("share", 1)))
            sums[p["kind"]] += seats * p["usd"]
        t = sums["verified"] + sums["assumed"]
        print(f"{c:<6}{people:>7}{sums['verified']:>10.2f}{sums['assumed']:>10.2f}{t:>9.2f}{t / people:>12.2f}")
    print("price sources:")
    for k, p in prices.items():
        share = f", {int(p['share'] * 100)}% of staff" if "share" in p else ""
        print(f"  {k:<17} ${p['usd']:.2f} {p['kind']}{share}: {p['source']}")


def main():
    d = load(sys.argv[1])
    problems = validate(d)
    print(f"{len(d['rows'])} systems, {len(d['columns'])} stages, {len(problems)} dependency problems")
    for p in problems:
        print("  ERROR", p)
    if problems:
        sys.exit(1)
    by_column(d)
    matrix(d)
    checklist(d)
    budget(d)


if __name__ == "__main__":
    main()

في السكربت أعلاه لاحظ التالي:

• الدالة validate تقارن موقع كل نظام بموقع ما يعتمد عليه، وتخرج قائمة مشكلات، والسكربت ينتهي برمز خروج 1 إذا وجد مشكلة، فيمكن تشغيله في خط CI عند كل تعديل على الملف.
• الدالة budget تجمع أسعار الأنظمة التي وصلت إليها المرحلة، أي أنظمة المرحلة نفسها وما قبلها، وتضرب كل سعر في عدد الموظفين أو في النسبة المحددة منهم، وتفصل بين المجموع المتحقق منه والمجموع المفترض.

التشغيل

نشغل السكربت في Container من Docker Image الرسمية python:3.13.16-slim، مع ربط مجلد التجربة للقراءة فقط:

cd lab
docker run --rm --name lab-org-matrix -v "$PWD:/lab:ro" -w /lab \
  python:3.13.16-slim python matrix.py org-systems.json

والمخرج سوف يكون كما يلي، وهذا القسم الأول منه، أي الأنظمة التي تضاف في كل مرحلة:

42 systems, 4 stages, 0 dependency problems
== 1. Systems added at each stage
-- S1 Day one (1-9 people): +11 (total 11)
   Backbone         Domain + DNS
   Backbone         Email + calendar + files
   Backbone         Directory (one account per person)
   Backbone         MFA on every account
   Backbone         Password manager
   Backbone         Backup + restore test
   Communication    Team chat + meetings
   Finance          Accounting + e-invoicing
   HR               Payroll + wage file
   Marketing        Website / CMS
   Operations       Task / project board
-- S2 10-20 people: +12 (total 23)
   Finance          Expense claims
   HR               HRIS (employee record)
   HR               Joiner-mover-leaver flow
   IT               SSO for every app
   IT               Device management (MDM)
   Legal            E-signature + contract folder
   Legal            Personal data register (PDPL)
   Marketing        Email marketing
   Marketing        Web analytics
   Operations       Internal knowledge base
   Sales            CRM
   Support          Shared inbox / helpdesk
-- S3 About 50 people: +11 (total 34)
   Backbone         Workflow automation
   Data             Dashboards (BI)
   Facilities       Room + desk booking
   Finance          Budget vs actual
   HR               Recruitment (ATS)
   IT               IT tickets (ITSM)
   IT               Asset register
   IT               Endpoint security (EDR)
   Leadership       Goals / OKRs
   Procurement      Purchase requests + approvals
   Support          Public help center
-- S4 200+ people: +8 (total 42)
   Data             Data warehouse
   Facilities       Visitors + maintenance requests
   Finance          ERP (finance + stock + purchasing)
   HR               Training / compliance courses
   HR               Performance reviews
   IT               Central logs + SIEM
   Legal            Contract lifecycle (renewals)
   Procurement      Procure-to-pay + vendor records

ثم القسم الثاني، وهو المصفوفة نفسها، أي عدد الأنظمة التي يضيفها كل قسم في كل مرحلة:

== 2. Department x stage (number of systems added)
department         S1   S2   S3   S4  total
Backbone            6    .    1    .      7
Communication       1    .    .    .      1
Finance             1    1    1    1      4
HR                  1    2    1    2      6
Marketing           1    2    .    .      3
Operations          1    1    .    .      2
IT                  .    2    3    1      6
Sales               .    1    .    .      1
Legal               .    2    .    1      3
Support             .    1    1    .      2
Procurement         .    .    1    1      2
Leadership          .    .    1    .      1
Data                .    .    1    1      2
Facilities          .    .    1    1      2
all                11   12   11    8     42

في المصفوفة أعلاه لاحظ التالي:

• العمود الأول مليء بالعمود الفقري Backbone، فستة من أحد عشر نظاماً في اليوم الأول مشتركة بين كل الأقسام، والمالية والموارد البشرية هما القسمان الوحيدان اللذان يبدآن بنظام خاص، والسبب الفاتورة والراتب.
• تقنية المعلومات IT لا تظهر في اليوم الأول، لأن نظامها في هذه المرحلة هو العمود الفقري نفسه، ثم تصبح أكثر قسم يضيف أنظمة في المرحلة الثالثة.
• عدد الأنظمة المضافة متقارب في كل مرحلة، من 8 إلى 12، أي أن الشركة تضيف قرابة عشرة أنظمة كلما تضاعف حجمها مرتين أو ثلاثاً، وهذا رقم يمكن التخطيط له.

الميزانية التوضيحية

القسم الرابع من المخرج يحسب تكلفة الاشتراكات لكل مستخدم في كل مرحلة، بعدد الموظفين المكتوب في الملف لكل مرحلة:

== 4. Per-seat subscriptions per month, USD (illustrative)
stage  people  verified   assumed    total  per person
S1          8     90.00     56.00   146.00       18.25
S2         20    225.00    480.00   705.00       35.25
S3         50    562.50   1200.00  1762.50       35.25
S4        250   2812.50   6000.00  8812.50       35.25
price sources:
  password_manager  $4.00 verified: bitwarden.com/pricing/business (Teams, billed annually), 2026-10-14
  chat              $7.25 verified: slack.com/pricing (Pro, paying annually), 2026-10-14
  suite             $7.00 assumed: placeholder for an email + calendar + files suite; put your quote here
  hris              $6.00 assumed: placeholder for an HRIS with payroll; put your quote here
  crm               $25.00 assumed, 20% of staff: placeholder per sales user; applied to 20% of staff
  helpdesk          $20.00 assumed, 10% of staff: placeholder per support agent; applied to 10% of staff
  mdm               $4.00 assumed: placeholder per managed device

في المخرج أعلاه لاحظ التالي:

• التكلفة لكل موظف تقفز من 18.25 دولار إلى 35.25 دولار في المرحلة الثانية، لأن نظام ال HRIS وال CRM والدعم وإدارة الأجهزة تضاف فيها، ثم تبقى ثابتة لكل موظف، بينما يكبر المجموع مع العدد، فيصل إلى 8812.50 دولار شهرياً عند 250 موظفاً.
• أكثر من ثلثي المبلغ في كل مرحلة بعد الأولى من الأسعار المفترضة، ولذلك فالرقم الكلي يتغير كثيراً بعروض الأسعار الفعلية، أما الشكل نفسه، أي أن التكلفة تكبر مع كل موظف، فهو ثابت.
• هذا الحساب يغطي الاشتراكات التي تسعر لكل مستخدم فقط، ولا يشمل المحاسبة وال ERP والاستضافة والإعداد والدعم ووقت الموظفين، وهذا الشكل هو ما يجعل الاستضافة الذاتية مغرية مع الحجم كما في تكلفة لا تكبر مع كل موظف جديد، بشرط أن تحسب وقت الفريق أيضاً.

اكسرها: نظام يأتي قبل ما يعتمد عليه

لنفرض أن مدير الموارد البشرية طلب نظام التوظيف ATS من اليوم الأول لأن الشركة ستوظف كثيراً، وأن تقنية المعلومات أجلت الدخول الموحد SSO إلى المرحلة الثالثة. سوف نعدل نسخة من الملف داخل ال Container ونشغل السكربت عليها، دون أن نغير الملف الأصلي:

docker run --rm --name lab-org-break -v "$PWD:/lab:ro" -w /lab python:3.13.16-slim sh -c 'python - <<EOF
import json
d = json.load(open("org-systems.json", encoding="utf-8"))
for r in d["rows"]:
    if r["id"] == "ats": r["col"] = "S1"
    if r["id"] == "sso": r["col"] = "S3"
json.dump(d, open("/tmp/broken.json", "w"))
EOF
python matrix.py /tmp/broken.json; echo "exit code $?"'

والمخرج سوف يكون كما يلي:

42 systems, 4 stages, 3 dependency problems
  ERROR jml (S2) needs sso, which only comes in S3
  ERROR kb (S2) needs sso, which only comes in S3
  ERROR ats (S1) needs hris, which only comes in S2
exit code 1

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

قائمة التحقق لكل مرحلة

القسم الثالث من مخرج السكربت هو قائمة التحقق نفسها، وهي جاهزة للنسخ كما هي:

== 3. Checklist (you need it when...)
-- Day one (1-9 people)
[ ] Domain + DNS: before the first email address
[ ] Email + calendar + files: first employee
[ ] Directory (one account per person): first employee
[ ] MFA on every account: first employee
[ ] Password manager: first shared password
[ ] Backup + restore test: first file you cannot lose
[ ] Team chat + meetings: first remote meeting
[ ] Accounting + e-invoicing: first invoice
[ ] Payroll + wage file: first salary
[ ] Website / CMS: first customer looks you up
[ ] Task / project board: two people on one piece of work
-- 10-20 people
[ ] SSO for every app: more than 5 apps or the first leaver
[ ] Device management (MDM): first lost laptop
[ ] HRIS (employee record): leave requests by email
[ ] Joiner-mover-leaver flow: an account left open after a leaver
[ ] CRM: second salesperson
[ ] E-signature + contract folder: contracts signed by scan and email
[ ] Shared inbox / helpdesk: a customer asked twice
[ ] Internal knowledge base: the same question answered 3 times
[ ] Expense claims: receipts in chat
[ ] Email marketing: first mailing list
[ ] Web analytics: first campaign
[ ] Personal data register (PDPL): first customer personal data
-- About 50 people
[ ] Recruitment (ATS): 5+ open roles at once
[ ] IT tickets (ITSM): IT requests lost in chat
[ ] Asset register: nobody knows who has which laptop
[ ] Endpoint security (EDR): first security questionnaire from a customer
[ ] Purchase requests + approvals: spend nobody approved
[ ] Budget vs actual: a department overspent and found out late
[ ] Goals / OKRs: teams pull in different directions
[ ] Dashboards (BI): the same number differs in 2 reports
[ ] Workflow automation: copying data between 2 systems by hand
[ ] Room + desk booking: double-booked meeting rooms
[ ] Public help center: top 10 questions repeat every week
-- 200+ people
[ ] ERP (finance + stock + purchasing): stock, branches or 3+ entities
[ ] Procure-to-pay + vendor records: duplicate vendor payments
[ ] Contract lifecycle (renewals): a renewal you missed
[ ] Training / compliance courses: mandatory training tracked in a sheet
[ ] Performance reviews: reviews in documents nobody finds
[ ] Central logs + SIEM: an audit asks who did what and when
[ ] Data warehouse: reports slow down the production database
[ ] Visitors + maintenance requests: several sites or a reception desk

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

تدريب عملي

• انسخ org-systems.json وعدله لمؤسستك: احذف ما لا تحتاجه، وأضف أنظمة قطاعك، وغير عدد الموظفين والأسعار المفترضة بعروض الأسعار التي لديك، ثم شغل السكربت.
• أضف إلى كل صف حقلاً باسم المالك، وعدل السكربت ليطبع الأنظمة التي ليس لها مالك.

الخلاصة

• الخطأ في التوقيت له اتجاهان: الشراء المبكر يبني الإجراء على شكل النظام، والشراء المتأخر يراكم بيانات يصعب نقلها.
• اليوم الأول للأساس وما تطلبه الجهات الرسمية: النطاق والبريد والدليل والتحقق الثنائي ومدير كلمات المرور والنسخ الاحتياطي والمحاسبة والرواتب.
• من 10 إلى 20 موظفاً يأتي الدخول الموحد ونظام ال HRIS وال CRM، لأن كل ما بعدها يعتمد عليها، ثم تأتي أنظمة الأقسام عند الخمسين، وأنظمة السجل والمراجعة بعد المئتين.
• العلامة هي التي تقرر وليس العدد وحده: موافقة بلا سجل، وعمل يتكرر، ومعرفة في رأس شخص، ورقمان مختلفان، وجهة خارجية تطلب سجلاً.
• في التجربة أضافت الشركة بين 8 و12 نظاماً في كل مرحلة، وقفزت تكلفة الاشتراكات لكل موظف إلى الضعف تقريباً في المرحلة الثانية، ورفض السكربت الملف عندما جاء نظامان قبل ما يعتمدان عليه.

وفي المقال الأخير من السلسلة سوف ننتقل إلى الجامعة، حيث تدور الأنظمة حول مسار الطالب من القبول إلى التخرج وليس حول عدد الموظفين.

دليلما الأنظمة التي يحتاجها كل قسم في مؤسستك؟الحد الأدنى من الأنظمة لكل قسم في الشركة، ومتى يحتاجه، وكيف تربطه بالهوية وسجل الموظف وسجل العميل.دليلالمصادر المفتوحة في الشركة الناشئة: ماذا تستضيف بنفسك ومتى؟دليل للمدير التقني في الشركة الناشئة يبين ما تستضيفه بنفسك من اليوم الأول، وما تتركه للخدمات المدارة حتى يكبر الفريق.دليلCapability Map: كيف تقرر مصير كل نظام في مؤسستككيف تبني خريطة لقدرات مؤسستك وتربط بها أنظمتك، لتكتشف التكرار والفجوات وتقرر ما تبقيه وما توقفه.

سجل التحديثات

• أكتوبر 2026: كتابة المقال مع سكربت Python 3.13.16 في Container من python:3.13.16-slim على Docker Engine 29.8.0، والأسعار من صفحات Bitwarden وSlack وGoogle Workspace كما هي في 14 أكتوبر 2026.