- 20
- March
ERP Implementation Planning for 2 Organization Sizes — 100 vs 300+ Users: What's the Difference?
Once executives decide to implement ERP, the next question is: "How do we prepare?" The answer depends on your organization's size. Implementation plans for a 100-person organization versus a 300+ person organization are fundamentally different. It is not just about "taking longer" — the team structure, data management approach, training strategy, and go-live method all change dramatically.
Quick Summary
- Organizations with up to 100 users (managing budgets up to 500M baht / ~$15M): Implementation takes 6-9 months, full Big Bang go-live
- Organizations with 300+ users (managing budgets of 1,000M+ baht / ~$30M+): Implementation takes 12-18 months, phased module Big Bang
- Both tiers use Big Bang (cut over from the legacy system immediately) — Parallel Run is not recommended
- The #1 success factor is client cooperation — the implementation team is there to support, not to determine success
Why Organization Size Changes the Entire Implementation Plan
Many people assume that a larger organization simply "takes longer." In reality, organization size changes everything — from team structure to the go-live strategy.
- Managing budgets of 500M baht (~$15M) vs 1,000M+ baht (~$30M+) — Budget structures differ in complexity. A smaller organization may have a straightforward plan/output/activity structure, while a larger organization has multiple layers, multiple funding sources, and multiple projects. Configuring the Chart of Accounts and budget system structure becomes far more complex.
- 100 users vs 300+ users — Change Management is a completely different challenge. A 100-person organization can hold a single briefing session and reach everyone. With 300+ people, you need a formal working committee, a Communication Plan, and Change Champions assigned to each department.
- Legacy data to migrate — Larger organizations have exponentially more historical data: accounting records, inventory, personnel, contracts. Data cleansing alone can take several months.
- More stakeholders — Communication becomes more complex, requiring coordination across multiple departments and management levels. Decision-making is slower, and meetings must be scheduled further in advance.
Saeree ERP vs. Saeree ERP Enterprise — Side-by-Side Comparison
The table below provides a detailed comparison of implementation plans between the two product editions, giving executives a clear overview before making decisions.
| Topic | Saeree ERP (up to 100 users, managing budgets up to 500M baht) | Saeree ERP Enterprise (300+ users, managing budgets of 1,000M+ baht) |
|---|---|---|
| Implementation Duration | 6-9 months | 12-18 months |
| Client-Side Implementation Team | 3-5 people (PM + Key Users from each department) | 10-20+ people (working committee + Key Users + IT) |
| Grand Linux Implementation Team | 3-5 people | 8-15 people |
| Work Phases | 1-2 Phases | 3-5 Phases |
| Budget Structure | Plan/Output/Activity | Multiple layers, multiple funding sources, multiple projects |
| Data Migration | 1-3 years of historical data | 5-10+ years + data cleansing |
| Training | 2-3 combined training sessions | 5-10 sessions by group |
| Go-live Strategy | Full Big Bang | Phased Module Big Bang |
| Change Management | Briefing sessions + Hands-on support | Working committee + Communication Plan + Change Champions |
Why Big Bang — How Parallel Run Fails in Practice
Big Bang = On a designated date, the legacy system is shut down immediately and everyone uses only the new system.
Parallel Run = The old and new systems run simultaneously, and results are compared.
In theory, Parallel Run sounds appealing — "Let's run both systems side by side first; if the new one doesn't work, we still have the old one as backup." But in practice, Parallel Run fails repeatedly for these reasons:
1. People refuse to do double work — Staff must enter data into both the old and new systems, effectively doubling their workload. Employees already busy with their regular duties will question "why do this twice?" and start entering data carelessly into the new system, leading to inaccurate records.
2. It drags on indefinitely — It starts as "3 months of parallel running," but there is always an excuse: "the numbers don't match yet" or "we're not confident enough." It stretches into a year. Eventually, the project never concludes, the budget balloons, and morale collapses.
3. The new system becomes the "stepchild" — People still trust the old system. Real data stays in the old system. The new system is neglected and nobody verifies its data seriously. When problems arise, the blame falls on "the new system is no good," when the real issue is that nobody bothered to enter data correctly.
4. Double the cost — Maintaining two systems means paying for two sets of licenses, two sets of support staff, and double the operational costs. The cumulative expense during the parallel period can exceed the entire cost of implementing the new system.
5. Real-world evidence — Organizations that cut over from their legacy system immediately actually go live faster and encounter fewer problems. When there is no way back, everyone must use the new system seriously. Issues are discovered and resolved rapidly.
But Big Bang Does Not Mean "No Preparation"
We know Big Bang is risky — but we let the client choose
We let the client choose, because each approach has different operational procedures. But if asked for our recommendation, we advise Big Bang because:
- Reduces everyone's workload — no need to key data into 2 systems
- Different processes make comparison difficult — the old and new systems have different workflows, different accounting entries, and results sometimes cannot be reconciled at end-of-day
Most clients, once they understand the pros and cons, choose Big Bang. But it comes with a trade-off: thorough system testing, full preparation, and comprehensive training — full cooperation is required. Blueprint, Configuration, Data Migration, Testing, Training — everything must be ready before the go-live date.
The Implementation Process — "Listen, Discuss Everything, Then Build"
Every success comes from clients who genuinely want to use the system and cooperate fully. Our role is to listen to every problem and adapt processes to reduce pain points as much as possible. Clients want to use the system, and we want to build something great for them. That's why our process doesn't just gather requirements and start configuring — instead, we sit down with the client in detail, raising every scenario, every condition, and every possible situation to reach agreement on all of them first, before configuring anything in the system.
1. Start with real documents, not theory
The first thing we do is request actual sample documents for every case the client handles — purchase requests, purchase orders, goods receipts, withdrawal slips, approval forms, budget reports, etc. We study the existing workflow in detail: how each step works, who's involved, and how documents flow through the organization.
2. Discuss every flow of the new system — every step, every condition
We then walk through the new system's workflow, asking deep questions that force the client to make decisions in advance on every issue:
- Will the new process be paperless? If so, starting from which part?
- Will approvals be signed in the system? What if an executive doesn't click approve in the system?
- How will documents be stored? When will they be printed? Or not printed at all?
- How many levels in the approval chain? Who checks what?
3. Raise every scenario that "might happen" — discuss it now
From working closely with many organizations, we've come to recognize which problems tend to recur. So we bring every one of these scenarios to the table early on, to agree on practical approaches together. For example:
Example scenarios we discuss upfront:
- "What if everyone in the approval chain clicks approve without actually checking, and the error is only discovered at the end?" → What policy or control should be in place?
- "What if the executive doesn't click approve in the system?" → Can an assistant approve on their behalf? Do we need a delegation rule?
- "What if someone requests materials but the executive hasn't approved yet — can they take the items first?" → The system won't allow stock deduction until approval is complete. But in reality, will someone release items early out of goodwill? If so, stock will be immediately inaccurate. This must be agreed upon in advance.
- "What if at year-end, multiple budget lines each have small remaining amounts — not enough individually, and nobody wants to do a formal transfer?" → Can budgets from multiple lines be consolidated? Who approves? What methods does the system support?
- "Could this situation actually happen?" → Let's discuss it now, not wait until it occurs.
The result: Some conditions we agree "can happen, but must have a defined procedure". Others that shouldn't happen are prevented by redesigning the process from the start — this is what we call "prevention before occurrence."
4. Prevention over reaction
Some problems that "might happen" never occur because we have organized the data and processes in advance. For example, issues with a misaligned Chart of Accounts are resolved during the Blueprint phase. Duplicate inventory data is cleansed before migration. Prevention is always better than reaction.
5. Standby team during the critical period
During the first week after go-live, the Grand Linux team is on-site full-time, assisting users and resolving issues in real time. For the first month, a dedicated hotline is available for urgent issues — no need to send emails and wait; call directly and get immediate resolution.
6. Ultimately, success depends on the client
Let's be direct — no matter how experienced the implementation team is, if the client doesn't cooperate, Big Bang will never succeed. The success of an ERP implementation depends entirely on the client. Grand Linux is merely a facilitator of your success — we help plan, ask the right questions, and prevent problems. But the people who actually make it work are the client's own team: they must make decisions, provide data, attend training, and have the courage to change. Read more about best practices for ERP implementation.
From Real Experience — Every organization that committed to cutting over from its legacy system on the designated date achieved a successful go-live. When there is no turning back, everyone must use the new system, and any issues that arise are resolved swiftly — this success belongs to the client, not to us.
Implementation Plan for Saeree ERP — Organizations with Up to 100 Users (Managing Budgets Up to 500 Million Baht / ~$15M)
Saeree ERP | Duration: 6-9 months | Full Big Bang Go-live
For organizations at this tier, the implementation plan is compact and straightforward. Both the client-side and Grand Linux teams are small, communication is fast, and decisions can be made immediately.
| Phase | Month | Key Activities | Responsible |
|---|---|---|---|
| 1. Analysis & Scenario Workshop | 1–2 | Collect real sample documents, study existing processes, discuss existing and new system flows for every step, raise all possible scenarios and agree on procedures, design Blueprint | PM + Key Users + Grand Linux |
| 2. Setup & Configuration | 3–5 | Configure system per Blueprint, set up Chart of Accounts, configure Workflows | Grand Linux + IT |
| 3. Data Migration | 5–6 | Migrate master data, opening balances, 1–3 years of historical data | Grand Linux + Key Users |
| 4. Testing & Training | 6–8 | UAT by Key Users, 2–3 rounds of end-user training | Key Users + End Users |
| 5. Go-live (Cutover) | 9 | Cutover: decommission legacy system → start using Saeree ERP immediately + Grand Linux team on-site for the first week | Everyone |
Note: For less complex organizations, implementation may be completed within 6 months.
Implementation Plan for Saeree ERP Enterprise — Organizations with 300+ Users (Managing Budgets of 1,000+ Million Baht / ~$30M+)
Saeree ERP Enterprise | Duration: 12-18 months | Phased Module Big Bang
"Phased Module Big Bang" means dividing modules into groups and going live one group at a time, with each group using Big Bang (no Parallel Run). For example, the first group goes live with Finance modules, followed by the second group with Procurement/Inventory/HR modules. Each time, the legacy system for that area is shut down immediately.
| Phase | Month | Key Activities |
|---|---|---|
| 1. Project Planning & Scenario Workshop | 1-3 | Establish working committee, collect real sample documents for every case, study existing processes, discuss every new system flow, raise all possible scenarios and agree on procedures, BPR, design To-be processes |
| 2. Core Modules (GL, AP, AR, FA, BG) | 4-8 | Configure core Finance modules, set up budget structure, migrate master data, UAT round 1 |
| 3. Extended Modules (PO, PR, IM, HR) | 7-11 | Configure Procurement/Inventory/HR modules (overlapping with Phase 2), migrate inventory/personnel data, UAT round 2 |
| 4. Integration & Full UAT | 10-14 | Full integration testing, 5-10 rounds of group-based end-user training, Mock Go-live, raise all potential issues with the client |
| 5. Go-live & Stabilize | 15-18 | Big Bang cut-over from legacy system, on-site team for 2-4 weeks, stabilization + urgent issue resolution, report adjustments |
For Saeree ERP Enterprise — We recommend conducting 1-2 "Mock Go-live" sessions, which simulate the entire real go-live scenario beforehand to uncover hidden issues, test approval workflows end-to-end, and familiarize users with the actual system.
5 Things Executives Must Do for a Successful Implementation
Whether you choose Saeree ERP or Saeree ERP Enterprise, there are five key actions executives must take to ensure a successful ERP project:
-
Provide genuine, visible support
This means more than just approving the budget and stepping away. Executives must attend key meetings, make decisions when departments disagree, and demonstrate that this project is an organizational priority — not just "an IT project."
-
Allocate sufficient personnel
Key Users must dedicate at least 50% of their working time to the ERP project — it cannot be "extra work on top of regular duties." Without adequate time allocation, UAT will lack thoroughness, training will be insufficient, and problems will surface after go-live instead of before.
-
Set a firm go-live date
Establish the date for cutting over from the legacy system at the very start of the project. Do not postpone unless absolutely necessary. A clear deadline creates positive pressure for everyone to complete their work on schedule.
-
Communicate across the entire organization
Everyone must know that a system change is coming, when it will happen, and how it will affect them. Effective communication reduces fear and resistance and helps personnel prepare for the transition.
-
Trust the process
Problems will inevitably arise during go-live — no ERP project is completely problem-free. But with proper preparation, every issue can be resolved. Read more about Is Your Organization Ready for ERP? 10 Questions to Answer.
Saeree ERP — Supporting Every Organization Size with a Single Engine
Saeree ERP for organizations with up to 100 users managing budgets up to 500M baht (~$15M) — backed by an experienced implementation team using a proven Big Bang approach that delivers results in 6-9 months with a lean team and rapid communication.
Saeree ERP Enterprise for organizations with 300+ users managing budgets of 1,000M+ baht (~$30M+) — running the same core engine but supporting complex, multi-layered budget structures with multiple funding sources and projects, backed by a large implementation team with extensive experience at this scale.
Both editions use a proven Big Bang approach validated by real clients. Read more about comparing ERP with SAP and how to choose the right ERP for your organization.
"Whether an ERP implementation succeeds or fails does not depend on the software chosen — it depends on the client's cooperation. We are merely facilitators who help ask the right questions and prevent as many problems as possible. The real success belongs to the client who has the courage to decide and commit fully."
- Grand Linux Solution Team
Summary
| Key Point | Summary |
|---|---|
| Organization size changes the entire plan | Up to 100 users = 6-9 months, 300+ users = 12-18 months |
| Go-live Strategy | Big Bang for both editions — Parallel Run is not recommended |
| Why Parallel Run fails | Staff cannot sustain double work; it drags on for a year; go-live never happens |
| Why Big Bang succeeds | Client cooperation + discussing every scenario upfront and preventing problems before they occur |
| #1 Success factor | Client cooperation — the implementation team supports, not determines success |
Need Advice on Your ERP Implementation Plan?
Consult with experts from Grand Linux Solution — free of charge
Request Free DemoTel. 02-347-7730 | sale@grandlinux.com
Related Articles from Knowledge Center
- Is Your Organization Ready for ERP? 10 Questions to Answer Executive
- ERP Project Preparation Checklist Implementation
- 10 Tips to Use ERP More Efficiently End User

