Toshio Koga | Director, SimLex Development Co., Ltd
I have been engaged in the design of SimLex ERP ever since I started the business. However, the concept of SimLex ERP did not suddenly materialize upon the company’s founding. Prior to establishing the company, it was built on a series of questions, workplace experiences, and years of accumulated thought driven by one core question: “Can this be simpler and more essential?”
Looking back, every experience and realization connected seamlessly to shape the design philosophy of SimLex ERP today. In other words, SimLex ERP is the direct reflection of the intellectual path I have walked. On this page, rather than highlighting product features or technical specifications, we introduce the origin story why SimLex ERP was built the way it is, what challenges were encountered, and how those experiences evolved into our core concepts. By understanding its development history, we hope you view SimLex ERP not just as another software product, but as an embodiment of the philosophy behind it.

Chapter 1: What happens if we eliminate that warehouse? Discovering Petri Nets

After graduating from university, I joined a major bearing manufacturer and was assigned to the Production Technology Research Institute, primarily focusing on inter-process logistics, material handling, and process design. While working on inter-process logistics design, my supervisor handed me a book saying, “Take a look at this.” Little did I know that this book would alter the course of my life.
The book detailed the theory of Petri Nets. The core idea of Petri Nets is strikingly simple: How can we model the real world using the absolute minimum set of essential elements?
One question in the book stunned me: What would happen if we eliminated that warehouse?
It struck a deep chord. Indeed, if a warehouse could be eliminated altogether, the work of moving goods in and out would instantly become obsolete. Managing warehouse operations, installing warehouse software, and maintaining the physical facility itself would no longer be necessary. Instead of making incremental improvements based on an existing warehouse, it challenged the fundamental premise: “Is the warehouse truly necessary in the first place?”
This mindset shift was a profound experience for my younger self. At the same time, I realized another critical truth: A warehouse generates no added value.
Placing a product inside a warehouse does not improve its quality; it is neither processed nor assembled there. On the contrary, maintaining a warehouse continuously consumes resources—facility costs, equipment, labor, handling efforts, and massive tied-up inventory capital. While temporary storage may sometimes be required in actual manufacturing, it is not because the warehouse itself holds value. What is truly needed is not the physical space, but the act of delivering items to the next process at the right time.
Once I realized this, the factory landscape I had always taken for granted looked completely different. Shifting from “How do we make warehouse management more efficient?” to “Can we eliminate the warehouse entirely?” became more than just a logistics improvement strategy for me. It became my foundational design principle: Do not make minor tweaks to existing setups; challenge their very existence and reduce them to their essence. This was the exact moment the core concept of SimLex ERP began to germinate.
Petri Nets taught me to conduct mental experiments: Remove an element simply because it is there out of long-standing habit. Remove it, observe what happens, and keep only what is genuinely indispensable. Decades later, this philosophy evolved into the commercial product SimLex ERP—a system designed not to mirror complex real-world operations, but to extract business essentials and redefine them into a sleek, efficient structure.
SimLex’s true starting point was not when the company was founded in 2012, but years earlier, on a desk at the Research Institute when I first opened that book on Petri Nets.

[Concept Breakdown] Petri Nets vs. SimLex ERP

In Petri Nets, complex real-world conditions are modeled using a minimal set of elements. SimLex ERP maps directly to this structure:
  • Token: Represents physical inventory.
  • Place: Represents a “state” (e.g., warehouse, work-in-progress, process step, shipment).
  • Transition: Represents a “change of state” (e.g., receiving, line input, completion, shipping) that moves tokens to the next place.
  • Firing: Execution of a transition, moving tokens to the next state.
The decisive factor here is not merely knowing how many items remain right now, but tracking the history of change—what moved, when, through which transition (event), and to where. As long as inventory movements are recorded completely as a “transaction log,” current stock levels can always be derived accurately through calculation.
Rather than simply storing a static inventory result, SimLex records the actual events causing the changes at a single source. The structural elegance of Petri Nets formed the foundation for SimLex ERP’s Single Source of Truth (SSOT) architecture.

Chapter 2: The Evolving Boundary Between Software and Hardware

During my time as an employee, I participated in a major project called “Next-Generation Equipment Development” as the person in charge of equipment handling, working alongside top engineers from various departments.
During our initial meetings and debates, I began to feel a sense of misalignment. The discussions focused almost exclusively on engineering specs: “What equipment specifications should we build?” and “How should we design them?”
I couldn’t help but question this approach. Equipment specifications shouldn’t be decided by machine designers in isolation. We needed to ask: “What is this equipment used for?” and “How does it fulfill customer demands as a whole system?”
To design equipment properly, one must trace back from top-level requirements:
$$\text{Customer Demand} \rightarrow \text{Production Planning} \rightarrow \text{Factory Layout} \rightarrow \text{Production Line} \rightarrow \text{Equipment Specs}$$
If you want to connect multiple machines into a production line, you must first define the required total throughput and setup flexibility. I strongly advocated for this structural viewpoint during the project, which led to intense debates with the project leader. Looking back, it was natural for us to see things differently: specialized engineers viewed the project microscopically (“How to build my specific machine”), while I viewed it macroscopically (“What overall factors determine the equipment’s specifications”).
Through these heated discussions, I arrived at another vital realization: The boundary between hardware and software is not absolute.
I began classifying concepts using Constraints and Variables:
  • Constraints: Parameters that are fixed and unchangeable at a given level of discussion.
  • Variables: Elements that can be reorganized and optimized within those constraints.
Crucially, this relationship shifts depending on your perspective (abstraction level):
Level Constraints (Hardware) Variables (Software)
Mechanical Design Purchased parts/components How to combine components into machinery
Line Design Individual equipment capabilities How to arrange equipment for optimal line capacity
Factory Design Production line layouts How to combine lines to optimize the entire plant
What is considered a fixed constraint (“hardware”) at a lower level becomes a customizable option (“variable”) at a higher level. “Hardware” and “software” are not fixed properties of an object; they depend entirely on the level of abstraction from which you view them.
This revelation—that constraints change with perspective—became the bedrock for designing SimLex ERP’s advanced hierarchical model.
It also marked a major turning point in my engineering career. To determine equipment specs, you must look at the production line. To design the line, you must look at the entire factory. To plan the factory, you must know what to produce and when—which is ultimately driven by customer demand. By following this logic, I naturally transitioned into the vast realm of Production Management.
  • In Chapter 1, I asked: “What happens if we eliminate the warehouse?”
  • In Chapter 2, I asked: “Is that constraint really a constraint, or just a matter of perspective?”
These two fundamental questions served as the primary catalyst for the SimLex ERP design philosophy that emerged decades later.

Chapter 3: Meeting the Mentor Who Introduced Me to MRP

After spending 13 years at the bearing manufacturer, I left to start my own company. Shortly after launching, I met an executive vice president from a subsidiary of a major motorcycle manufacturer. Together, we set out to co-develop a production scheduling program tailored for parts manufacturers.
This gentleman had previously worked at the parent company and was a true pioneer who introduced Material Requirements Planning (MRP) into operational practice back in the 1970s—a time when the term “MRP” was virtually unknown in Japan. He was a foundational figure in Japanese production management.
Through countless discussions with him, I learned the true essence of production management. Until then, as a production engineer, I had viewed job sites purely from a physical standpoint: how materials flow and how equipment is laid out. For the first time, I was exposed to a brand-new perspective: systematically viewing production activities as flows of information.
The concepts I learned were remarkably simple, yet packed with the core truths of production management:
$$\text{Order Management} \rightarrow \text{Master Production Schedule (MPS)} \rightarrow \text{MRP (Material Requirements Planning)}$$
Receiving customer demand, converting it into a production plan, and exploding requirements down to parts and raw materials seemed straightforward. But when viewed as an unbroken, continuous process, the entire structure of production management became strikingly vivid.
The MRP logic itself was elegant. By breaking down the Bill of Materials (BOM), it derived required quantities and timing. Highly complex factory management could be expressed through clear, concise logic. I was deeply captivated by this structural beauty.
Equally decisive was learning Entity-Relationship Diagramming (ERD) for database design. Structuring key manufacturing elements—items, BOMs, routing, sales orders, and production plans—as logical relationships allowed us to capture data not just as isolated facts, but as interconnected data models. This knowledge became an invaluable asset when I later architected the SimLex ERP database.
For someone from a production engineering background, this world of data was completely fresh. I had lived in a world of physical things: physical plants, machinery, and parts moving along lines. Learning MRP revealed that beneath the physical layer lies a real-time, orderly “information world”:
$$\text{Order} \rightarrow \text{Production Plan} \rightarrow \text{BOM Explosion} \rightarrow \text{Requirements \& Timing Calculation} \rightarrow \text{Procurement \& Manufacturing}$$
I gained deep respect for the pioneers of the 1970s. Long before modern computing or advanced databases existed, they had thoroughly analyzed manufacturing essentials to create the complete theoretical framework of MRP. Our job as a newer generation was not to dismiss past theories, but to inherit that wisdom and build upon it using modern technologies and fresh philosophies.
Equipped with MRP theory and my own hands-on experience in equipment, routing, logistics, and scheduling, a fundamental question emerged:
“Is it truly necessary to separate MRP and Schedulers into two distinct systems?”
MRP calculates what, when, and how much needs to be produced. A scheduler determines specifically when to produce within the real constraints of machines and processes. If these two could be fully integrated rather than kept separate, we could achieve high-precision production management that perfectly mirrors real-world factory floors.
This marked my first step into a new domain: the total integration of MRP and Scheduling. Looking back, meeting this great mentor was far more than just acquiring knowledge.
  • Chapter 1 (Petri Nets): Grasp reality through simple structures.
  • Chapter 2 (Constraints): Transform constraints into variables by shifting levels of abstraction.
  • Chapter 3 (MRP & ERD): Model production activities as structured information flows.
The disconnected dots of my past experience finally connected into a line, driving me forward toward the creation of SimLex ERP.

Chapter 4: “Optimizing Simplification” and Hitting the Limits of APS

To truly merge MRP and scheduling, countless real-world factory constraints must be precisely represented within the system. However, conventional schedulers suffer from an explosive growth in required master data:
  • Equipment operating hours, capacities, alternative machinery, and priorities
  • Fixed setup times occurring regardless of previous items
  • Variable setup times dependent on previous items
  • Production priorities driven by color, material, or temperature changes
  • Worker counts, skill levels, and shift patterns
Attempting to register every combination as individual master entries creates astronomical volumes of data. For instance, if paint colors, materials, and temperatures each have multiple variations, master records must be created for every possible permutation. Maintenance becomes impossible, and operational overhead paralyzes the site.
This is where my core design philosophy—Optimization through Simplification—demonstrated its full power.
Here, “simplification” does not mean simply cutting out information.
  • Simplification: Extracting the essence of reality and abstracting it to a higher conceptual level.
  • Optimization: Fulfilling overall system functionality by maintaining harmony across datasets, rather than over-optimizing individual master records in isolation.
Consider an example where production priority for a new item depends on the paint color or material of the previously produced item. A naive approach requires manually creating master entries for every pairwise combination: White $\rightarrow$ Black, White $\rightarrow$ Grey, Black $\rightarrow$ White, and so on. With thousands of items, combinations quickly reach millions.
Instead of mapping items directly, I abstracted the problem into Quality Characteristics:
  • Characteristic 1 (Paint Color): White, Grey, Black
  • Characteristic 2 (Material): Material A, Material B, Material C
Item masters carry only attributes (e.g., Paint Color: White / Material: A). Master definitions then specify priorities based on characteristic transitions rather than item combinations:
  • White $\rightarrow$ Black: Priority 3
  • White $\rightarrow$ Grey: Priority 2
  • Same Color Group: Priority 1
Even if items scale into the thousands, master data volume remains minimal. Abstracting the underlying characteristics rather than hardcoding items is the essence of Optimization through Simplification. The Quality Characteristic Master is not merely a data-entry trick; it is an architectural approach to reconstructing complex reality into a sleek, minimal structure.
To ensure rapid execution, these simplified master structures were loaded directly into an in-memory database. Aligning the physical database with memory structures eliminated complex data transformation logic in code. This produced a powerful virtuous cycle:
$$\text{Simpler Masters} \rightarrow \text{Simpler Memory Structures} \rightarrow \text{Simpler Code} \rightarrow \text{Blazing Fast Processing}$$
Using this architecture, I successfully built an advanced APS (Advanced Planning and Scheduling) system that fully unified MRP and scheduling. MRP calculated what, when, and how much, while the scheduler mapped operations against machine, labor, and process constraints. It was a major leap beyond traditional production planning.
Yet, my excitement was short-lived as I soon hit a massive wall.

The Limits of APS: Why APS Alone Cannot Save a Factory

At its core, APS remains a planning-centric system. While it can maximize schedule precision, planning is only one piece of the broader production management ecosystem.
Production management is not merely about drawing precise future schedules. A factory functions effectively only when the complete PDCA cycle turns smoothly: Plan$\rightarrow$Do$\rightarrow$Check (capture actuals) $\rightarrow$Action (reflect results in the next plan).
This requires an unbroken data backbone:
$$\text{Sales} \rightarrow \text{Purchasing} \rightarrow \text{Production Planning} \rightarrow \text{Actuals} \rightarrow \text{Inventory} \rightarrow \text{Costing} \rightarrow \text{(Next Plan)}$$
APS possessed an exceptional planning engine, but sales, purchasing, shop-floor actuals, inventory, and costing were not linked as an integrated ecosystem.
“APS elevates production planning, but planning alone does not equal production management.”
Recognizing this structural limitation forced a major decision. I had climbed one peak by unifying MRP and scheduling, but from the summit, I saw a far vaster ocean of challenges that the existing APS framework could never solve.
Continuing along the existing path would yield no answers. I needed to reset my thinking to zero and step into a new journey to rethink the entire system architecture.

Chapter 5: Why We Built a Custom Development Framework — Eliminating Person-Dependency & Achieving Metadata-Driven Architecture

As I stood at a major crossroads deciding which path to take after hitting the limits of APS, technological advancements accelerated around me. The software industry was experiencing a massive shift toward .NET. As both a business owner and an engineer, I couldn’t treat this as a simple language upgrade; I saw it as the perfect opportunity to rethink software development as a whole.
At the time, our scheduler was built in C++ for maximum processing speed, while master and transaction data were managed using MS-Access. However, developing with MS-Access carried two major operational risks:
  1. Direct vulnerability to Microsoft version updates and specification changes.
  2. High reliance on individual developer habits, leading to person-dependent code.
The latter posed a severe business risk. A talented programmer can finish a system, but what happens if they leave? Can another developer decipher and maintain that dark, chaotic code?
I felt an urgent need to eliminate person-dependent development. While adopting C# (.NET), I decided to custom-build a proprietary Development Framework from scratch.
The goal was simple: Ensure any programmer can easily maintain code written by others.
From day one, we established firm core principles:
  • Multi-DB Compatibility: Seamless support for major databases (Oracle, SQL Server, MySQL, DB2, MS-Access).
  • Automated DB Management: Schema initialization and differential updates executed directly via the Framework.
  • Global Readiness: Standardized, built-in multi-language switching.
  • Metadata-Driven Configurations: Database storage for screen layout properties, menu structures, and user permissions.
  • Excel Integration: Standardized no-code data import/export and document reporting.
Instead of writing custom code for every screen, developers would rely on a shared, reusable engine. This became the foundation for the SimLex Framework.
Here again, Optimization through Simplification delivered massive results—most notably in Screen Definition Abstraction. I asked myself: “What does it actually mean to design a user interface?”
This yielded a core realization: Every UI element is simply a form resource.
Text fields, drop-down menus, buttons, labels, titles, and tabs—rather than hardcoding these individually, we abstracted them into structured resource definition data. Custom screen programming became entirely unnecessary. Defining resources and properties in the database allowed the Framework to load and dynamically render screens at runtime.
Abstracting the essence reduced code volume dramatically, making programs clean and reducing software bugs to near zero.
By 2005, the Framework prototype was complete. Its lasting impact remains embedded in SimLex ERP today. While SimLex ERP contains approximately 1,200 screens, they were not coded individually. All 1,200 screens are dynamically driven by combining just 8 standard layout templates running on the Framework engine.
Instead of building individual screens one by one, we built an engine to generate screens automatically. This was the essence of our Framework.
Completed in 2005, this Framework evolved continuously and remains the core engine of SimLex today. By simply modifying database metadata, the system adapts flexibly to create business applications for virtually any industry.
I later learned that modern IT terminology calls this architecture a Metadata-Driven Application Platform. At the time, I knew nothing of such buzzwords; I simply searched for an elegant, robust way to eliminate reliance on individual programmers, and first-principles thinking naturally led to this structure.
Looking back, an unbroken thread connects my system philosophy from Chapter 1 onward:
  • Chapter 1 (Petri Nets): Model reality using minimal essential elements.
  • Chapter 2 (Equipment Design): Shift levels of abstraction to make constraints flexible.
  • Chapter 3 (MRP & ERD): Model production activities as structured information flows.
  • Chapter 4 (Scheduler): Abstract complex production conditions into quality characteristics.
  • Chapter 5 (Framework): Abstract UI elements into metadata to dynamically auto-generate applications.
Everything pointed in the same direction: Do not bring messy reality directly into complex code. Extract the essence, abstract it, and express it through a minimal, beautiful structure.
Yet, despite completing this innovative Framework, the underlying challenge remained: building a solid framework did not magically remove the structural limits of APS.
We had merged MRP and scheduling, simplified complex constraints, and built a framework that dramatically streamlined development and maintenance. Yet, my ideal of “true production management” remained out of reach.
“What should I do next?”
I made the biggest decision of my life: abandon past achievements and existing frameworks entirely, and redesign everything from a completely clean slate.

Chapter 6: Believing in the “Global Standard” Through Relocation to Thailand

Having hit the operational limits of Advanced Planning and Scheduling (APS), I went so far as to custom-build a foundational “Development Framework” to overcome them. Yet, I still lacked that decisive sense of fulfillment.
“Should I reset everything back to zero and rethink this from the ground up?”
A major concern weighed on my mind: “If I stay in Japan and keep building software, won’t I just end up making another conventional Japanese system, continuing along the exact same path?”
From my perspective at the time, Japanese production management systems were overly biased toward just two aspects: Production Planning and Process Control. While these are undoubtedly vital, production management cannot exist in isolation. A true production management system only exists when the entire operational chain is seamlessly linked into a single, robust data structure:
$$\text{Sales} \rightarrow \text{Purchasing} \rightarrow \text{Production Planning} \rightarrow \text{Manufacturing} \rightarrow \text{Actuals} \rightarrow \text{Inventory} \rightarrow \text{Costing}$$
Fortunately, having previously established a subsidiary in Thailand, I already understood the real-world conditions of local manufacturing plants. I completely abandoned the idea of simply taking a Japanese system and localizing it for Thailand. Instead, I resolved: “I will rebuild the entire architecture of production management from scratch in a brand-new environment free of constraints.”
With that determination, I made the major decision to relocate to Thailand. Several key reasons drove this choice:
  • It was an ideal development environment to build and test a system completely from scratch.
  • A massive base of Japanese manufacturers had established operations there, creating huge on-the-ground market demand.
  • Unlike Japan, it offered an open environment where even a new startup could compete independently in the market.
  • It was largely unburdened by the legacy concepts and vested interests of major IT vendors and consulting firms.
  • The moral values and character of the Thai people aligned deeply with my personal philosophy.
In August 2012, I moved to Thailand and established a new local entity with a small, lean team.
Immediately upon relocating, I immersed myself in development from morning till night. Just four months later, in December 2012, we completed the prototype for our new production management system.
When intense development left my mind exhausted, I visited local billiard halls for a change of pace. Billiards was immensely popular in Thailand, attracting a diverse crowd of locals as well as expats from Europe, America, India, and across the globe. Beyond the enjoyment of the game, making friends across nationalities became an unexpected and priceless asset. Through daily conversations, I absorbed authentic English and cross-cultural mindsets that no textbook could ever teach.
It was during these interactions that I realized a fundamental truth: Regardless of nationality, race, or culture, human emotions and thought processes are essentially the same. People feel confident, vulnerable, or anxious when cornered. They feel genuine joy when winning and deep frustration when losing. At their core, human beings do not differ much whether they are Japanese, European, or American. This intuitive realization became a vital mindset when defining my concept of a “Global Standard.”
During this period, I also provided maintenance support and system development for a local machinery manufacturer. Observing local Thai staff and learning how they executed daily tasks brought the operational differences between Japanese and overseas job sites into sharp focus:
“Simply making minor tweaks to Japanese methods for the Thai market will never succeed globally. What we need now is neither a strictly ‘Japanese style’ nor a ‘Thai style.’ It must be an overwhelmingly superior ‘Global Standard’ system capable of performing anywhere in the world.”
I set my destination: Building a Global Standard.
However, a massive question immediately arose: “What, exactly, is a ‘Global Standard’?”
  • Is it adopting every unreasonable demand from companies around the world into the system?
  • Is it accommodating every vague local rule from different countries into the software?
  • Is it cramming in as many features as possible to build a massive system?
Upon cool reflection, the alluring phrase “Global Standard” offered no concrete vision on its own. Searching in the dark, I returned to the roots of MRP and the lessons from my mentor in Chapter 3. What I had learned was a beautifully streamlined core process:
$$\text{Sales Order} \rightarrow \text{Master Production Schedule (MPS)} \rightarrow \text{MRP} \rightarrow \text{Purchase Order} \rightarrow \text{Work Order} \rightarrow \text{Actuals} \rightarrow \text{Inventory Management}$$
“Building this core process with complete structural integrity and correctness—without compromise—is the true meaning of the ‘Global Standard’ I am searching for.”
I was convinced. A global standard is not about bloating a system by swallowing every random requirement worldwide. It is about stripping away unnecessary excess and constructing the true essence of production management into a flawless data structure.
  • Chapter 1 (Petri Nets): Model real-world complexity using the minimum number of essential elements.
  • Chapter 2 (Constraints): Raise the level of abstraction to transform rigid constraints into flexible variables.
  • Chapter 3 (MRP): Adhere strictly to the essential core data flows.
  • Chapter 4 (Simplification & Optimization): Abstract complex conditions and control them via minimal master data.
  • Chapter 5 (Framework): Dynamically generate system components from metadata configurations.
By 2012, in the new setting of Thailand, everything was in place to rebuild my accumulated technical philosophy into a single grand structure. Driven by the unwavering conviction to create a true Global Standard ERP, the full-scale development of SimLex ERP officially began.

Chapter 7: Developing Sales, Production, and Accounting from Zero

Though developing entirely from scratch, the architecture was already crystal clear in my mind; it was simply a matter of translating the design into code. I had this confidence because we already possessed a powerful proprietary Development Framework.
For the user interface, I decided to build all screens using just 8 standard layout templates. Rather than coding individual screens from scratch, we used the Framework as a shared foundation to build Sales, Production, and Accounting on top.
We set strict design principles for the development phase:
  • Master Data Integration: Full import/export flexibility via the Framework’s standard Excel interface.
  • Transaction Data Integration: Ability to import and export all transactional data (e.g., Sales Orders) via Excel and CSV.
  • UI Standardization: Unifying all operational screens (Sales, Invoicing, Purchasing) into a standardized Header/Detail structure.
  • Data Integrity: Banning physical deletion of registered transaction data; all cancellations must be processed via reversal entries (credit notes) to maintain a complete audit trail.
  • High-Speed Hybrid MRP: Supporting a hybrid of Project Code Management and standard MRP, processing all requirements calculations super-fast in-memory.
  • Code-Free Reporting: Utilizing the Framework’s standard Excel reporting module to generate and modify documents flexibly without programming.
Grounded in these principles, we set a target to complete the prototype in four months.

Inventory’s “Single Source of Truth”

When designing inventory management, I focused heavily on consolidating all inventory movements into a single transaction file: the Stock Transaction Log.
Diverse operational views—such as inventory by location, item, lot, or Stock Cards—were not maintained across multiple duplicate tables. Instead, they were dynamically aggregated on demand from the original Stock Transaction Log.
While the term “Single Source of Truth” (SSOT) was not widely popularized then, looking back, this was the exact origin of SimLex’s SSOT architecture. Rather than storing static inventory numbers scattered across multiple tables, we centralized the actual event logs as the single truth, deriving all required reports and views directly from them. This core principle came to form the backbone of the entire SimLex ERP platform.

Initial Adoption and the Challenge of Accounting

Once the prototype was complete, we immediately launched our sales effort, pitching SimLex’s production system to major electronics manufacturers and consulting firms.
These efforts paid off when we secured an implementation for the Thai subsidiary of a company listed on the First Section of the Tokyo Stock Exchange (via a major electrical equipment manufacturer). This deal provided vital cash flow that sustained our early operations. (That client adopted our production management system and continues to use it to this day.)
Then, a pitch to a consulting firm brought our next major turning point:
“Can you also build an accounting system within SimLex?”
Without hesitation, I replied: “Yes, we can.”
While I accepted immediately, to be honest, as a business manager I knew how to read a Balance Sheet (B/S) and Profit & Loss Statement (P/L), but I was not deeply versed in internal journal entry logic or general ledger generation. Nevertheless, my personal rule has always been: Once you commit, you execute no matter what.

Localized Development Across Borders

I threw myself into developing the accounting system and completed a prototype by May 2013. However, the real battle had just begun.
Local Thai accounting packages were deeply entrenched in the market. As a late entrant, SimLex received sharp feedback from local accountants regarding missing features and localized reporting requirements. We rigorously evaluated each requirement and rapidly implemented missing functions. It took over six months of intense refinement before the accounting module reached a truly satisfactory level in December 2013.
Two areas proved particularly challenging: Flexible Voucher Numbering and Compliance with Southeast Asian Accounting Standards.
Overseas business practices feature far more diverse voucher numbering rules than Japan:
  • IVyyyyMMxxx (Resetting sequence numbers monthly)
  • yyyyxxxxxx (Resetting sequence numbers annually)
  • [Customer Code] + yyyyMMxxx (Separating numbering rules by customer)
To handle these variations flexibly, we turned numbering rules into master settings, allowing users to select and apply rules freely when generating documents.
Additionally, countries like Indonesia required distinct exchange rates for tax filings (VAT official rates) versus commercial transactions (AR/AP market rates), presenting unique local rules distinct from Thailand. We systematically addressed each regional requirement one by one.

Full ERP Integration and the Final Hurdle

The completed accounting system integrated seamlessly with the production system at the ER diagram level. Sales, Production, and Accounting were no longer isolated, silographical software units; they formed a tightly aligned single data model.
Journal entries for inventory movements were not manually re-entered into accounting. Instead, they were generated automatically and directly from production transactions. Here, too, the Single Source of Truth philosophy held firm: Never duplicate data across multiple systems; use source data as the single truth to derive necessary ledgers and journal entries.
With sales, production, inventory, and accounting linked through a unified core, the structural framework of SimLex ERP was complete. Yet, one final hurdle remained before it could be considered a fully realized ERP: Cost Management.
At that time, our costing features remained basic. But with inventory and accounting fully unified, cost accounting could not be left as a simplified system. Because production and accounting were directly linked, cost management had to be redesigned under the very same philosophy.
This drove me to embark on my next major challenge: a complete overhaul of the Costing Engine.

Chapter 8: Rethinking “Machine/Labor Rates” During Cost Engine Development

The early cost management engine in SimLex ERP relied on standard, simplified cost accounting. Process masters were configured with pre-set Operation Rates (hourly labor/machine charge rates), calculating and accumulating standard unit costs for each process and item. For typical system requirements, this was considered sufficient.
However, during development, a fundamental doubt began to take root in my mind.
When I asked client companies, “When and how did you calculate these operation rates?”, the responses were troubling:
  • “We’ve been using the figures set when the factory was established.”
  • “We just input whatever rates headquarters in Japan sends us.”
While not true for every company, many job sites were relying on numbers completely detached from real-world manufacturing costs.
In practice, operation rates were typically compiled by a specific individual fluent in both accounting and production, using complex Excel spreadsheets.
“Why does such an ambiguous, person-dependent concept like ‘operation rates’ exist in the first place?”
Analyzing the root cause revealed a structural issue: Japanese corporations maintained strict organizational silos between Production Management and Accounting. The “operation rate” was created merely as a convenient buffer to bridge these two disconnected departments, hiding the underlying calculations inside a black box in someone’s head.
If operation rates are never updated, costs continue to be calculated based on outdated historical benchmarks, rendering it impossible for executives to make sound strategic decisions. Above all, relying on static operation rates masks basic cost dynamics—such as product unit costs rising when production volumes fall due to unabsorbed fixed overhead.
At this point, I returned to the foundational question from Chapter 1: How can we model reality using only the minimum set of essential elements?
What are the true essential components of cost? When stripped to their essence, only two elements remain:
  1. Actual expense data exported from Accounting
  2. Quantity, production time, and purchase price data recorded in the Stock Transaction Log
Operation rates do not exist as an essential component of cost in the first place.
“If that is the case, why not calculate cost by directly connecting actual accounting expenses with transaction log data?”
This yielded a logical and natural methodology. While even major global ERP packages use machine and labor charge rates for cost calculations, thinking from first principles gave me complete confidence that my approach was correct. Thus began the development of a new cost management engine built from fundamental truths.
The greatest challenge during development was that Accounting Cost Centers and Factory Processes rarely match on a 1:1 basis.
We solved this by introducing an Allocation Master that properly distributed GL account data to individual processes. Account items—such as direct expenses, indirect expenses, shared overhead, and depreciation—were mapped to processes to calculate accurate operation expenses automatically.
By standardizing allocation rules into master settings, we eliminated black-box reliance on specific individuals, making the cost management structure clear and accessible to anyone.
With this, SimLex ERP’s definitive cost management system was complete, supporting Standard Costing, Actual Costing, and Budgeted Costing seamlessly. In the SimLex architecture, conventional operation rates are no longer an input variable, but a calculated output derived automatically from actual operations.
The validity of this logic was quickly proven in the field. When deployed at a major manufacturer producing precision components for the iPhone, SimLex ERP’s calculated cost data passed the rigorous audit of a major Japanese accounting firm without issue. Questioning conventional ERP assumptions and building from first principles proved successful on a global standard.
However, while the software was complete, we encountered a different obstacle on the ground: local Thai financial auditors were often unfamiliar with advanced managerial accounting concepts like standard costing, actual costing, and variance analysis, adhering strictly to actual-cost-only practices. Historical differences between Japan and Thailand meant that cost philosophies and operational maturity varied significantly, leaving us with operational challenges on how to navigate differing accounting cultures.
Nonetheless, Sales, Production, Accounting, and Costing were now fully integrated into a single, robust structure under the Single Source of Truth philosophy.
Thank you for reading the story behind the creation of SimLex ERP. If you have any feedback or inquiries, please feel free to reach out via email: