Software in the implementation process

Optimistic start A company just decided to embark on a TOC project – seeing the incredible benefits it can gain from it The company purchased books about TOC The company has done a strategic analysis (possibly with the help of expert TOC consultants) to understand the value TOC can provide it The company decided on a full scale TOC implementation What are the possible problems? We do assume our solutions are truly good!

Problems in implementation Buy in Employees Why am I doing this? It’s hard work Management Does this TOC solution really deliver? Support functions – mainly IT Why are we doing all this extra work? Will they get rid of us later? Errors in implementation Non-adherence to SOPs Accepting wrong decisions due to errors

The need for IT Embarking on TOC at the conceptual level is not enough – the company must have also the IT system to support it Support on the technical level We expect the outcome of IT to fully conform to the SOPs Support in robustness of SOPs Truly good IT makes it easier to implement the SOP and ensures they are followed Sustainability of the change in SOPs

The current system Whatever system the organization have – any kind of ERP – will not support the TOC concepts Especially the differentiation TOC makes between Planning and Execution ERP does planning, without full consideration of the uncertainty, and builds everything around it. Execution in ERP means re-planning as much as necessary Execution in TOC – buffer management – means prioritizing based on changing reality WITHOUT re-planning

Make or Buy There are basically two main options for IT systems to support the TOC concepts: Make – build a solution either as part of the ERP system (add-on) or external to the ERP Buy – purchase a ready-made TOC software that comes on top of the ERP The right decision will impact the implementation – the better option will be able to solve the problems in implementation

Custom-made development myths Myth: It’s considered cheap as it’s done with internal resources Reality: the internal people have to go through extensive training to be able to understand properly the demands from the software, and the investment is an on-going one as the knowledge keeps developing and the needs are changing – making the investment quite high

Custom-made development myths Myth: The organization can change it at will – for better usability and all reports possible Reality: This is probably the highest risk – by letting the users change the application there is not sufficient debate over whether a specific feature is really needed or the opposite. Also – this requires constant training to all users on the TOC principles as non-TOC thinkers will ask for a reverse of the TOC features causing a reverse in the results achieved as well

Custom-made development myths Myth: Since the solution is simple, it will take very short to develop Reality: Nothing could be further from the truth. The simplicity of the solution is such that it requires very high precision not only in the technical side but especially on the logical side. The QA people that need to test this software need to be very proficient in TOC – to be actually TOC experts themselves

Custom-made development myths Myth: a custom-made system has a very good integration with current order-entry system Reality: This is true – a system developed on the order entry system itself will have better integration than otherwise. However, it will also suffer from the fact it was developed under the order-entry system – any upgrade of the order-entry system might make the software not function correctly – and who is able to test this?

Solving the problems Buy in Employees – need a system that is easy to manage (supports buy) Management – need to see fast results from the implementation (support buy) Support functions – mainly IT – usually prefer to make a solution as it enables them to achieve more power (support make) Errors in implementation Non-adherence to SOPs – the system must make it easy to follow and monitor adherence (supports buy) Accepting wrong decisions due to errors – the system needs to be thoroughly tested (supports buy)

Speaker Amir Schragenheim – Prezident of Inherent Simplicity, Software for building decisive competitive edge at: Production environment Distribution environment Retail environment See us at: http://www.inherentsimplicity.com