In most manufacturing companies these ideas would require a significant investment in time and money and, most likely, will not fully satisfy the requirements when the project is finished. Typical implementation usually follows these steps.
The functional manager or the operations committee is required to define the desired new process outlining in detail what is to be changed. This usually requires an "as is" view along with a “to be” vision.
Step 2. When the operations committee has completed their homework the project is turned over to the IT department for development and implementation. IT is not typically sitting on their hands with nothing to do. They have an existing backlog of work that requires the new project to be examined for its worth and put into the queue based on some evaluation process. The IT analyst begins by delving into the project requirements and examining the ability to satisfy the project needs using as much existing information tools and data as possible. A budget has been set and it is the analyst’s job to meet the requirements within the cost constraints. Based on the analyst’s concept, a detailed plan is built identifying all the systems work necessary to do the job. A fundamental part of this is the graphical outline of the process indicating process steps such as events, inputs, decision points, etc. The programmers swing into action developing new code to fit the application based on what they interpret from the analyst’s presentation. Code is written and tested, and equipment is purchased. The finished product is presented to operations. Necessary changes are made to debug the system, respond to new requirements, and address requirements that could not be met. The operations committee finalizes and accepts the end product in spite of changes that should be made based on items not seen prior to coding and implementation. Business conditions have changed and some revisions to fully satisfy the users are requested. IT is busy so the requested changes must be again put into the queue awaiting action. Typically, when there is available staff to make the changes, the original person or group is on another project and the learning curve restarts from some point just above zero. Step 3. Step 4. Step 5. Step 6.