In this first article, I will share how 1) "Process Thinking" was reflected in the roll-out approach, 2) how weekly whiteboards huddles made problems visible and engaged cross-process cooperation, and 3) how agile techniques helped us esp. in the testing phase.
The company subsidiary where I worked, was the second one to go live on the SAP system. Previous implementation experience had shown that major disconnects occured in the processes especially between departments. In an integrated ERP system, all processes are linked: a simple mistake in product master data can cause products not to be orderable from customers, not to purchaseable from vendors or not to be received in the warehouse. Hence, the way of looking at the organisation was enhanced from a solely departmental perspective to a process perspective as well. The additional conceptual layer, the process model, was put on top of the functional silo's. This layer introduced a new language -a new standard- e.g. Order to Cash covering the activities from creating a quotation and an order (sales), credit checking (finance), calculation of estimated delivery date, billing (finance) and collections (finance). This reflects the essence of the 2nd Lean Principle, that customer value is created by a value stream.
In theory this sounds logical and simple. In practice this had major consequences. The entire project organisation, for design and implementation of the SAP processes and solution, was organised in Process Teams e.g. Order to Cash, Procure to Pay, Receive to Ship. Supply chain folks were now teaming up not just with their own peers but also with the accounts payable folks and with the teams maintaining vendor master data. Process owners, supported by process leads, were assigned to own the design and functioning of the main end-to-end processes. In the design of an EPR functional solution, few decisions can be taken in isolation. [By the way, after dissolvement of the project organisation, the value stream specialist role remained. It proved to be a challenge for these specialists, who always belonged to one functional organisation as well, to focus their efforts on the end-to-end proces they were responsible for. For example: a sales specialists was required to master the billing and credit processes as well.]
When replacing your existing processes and systems with an entirely new one, and the existing solutions in SAP are known to be incomplete, how do you keep overview of all issues and dependencies whilst preparing for a go-life. We introduced weekly boardwalks, where the process team leads were updating eachother on progress, were issues were raised to sponsors and dependencies between team and processes were managed.
PMO board
Project board - Order to Cash
Project board - Product Life Cycle
We experimented with some agile development practices, without having the true agile in place. Development was done in sprints, which allowed for better tracking of deliverables on time and useability. Burn down charts revealed that no development ever went according to plan. In some area's daily scrum meetings made problems visible between teams and had multi-disciplinary teams work together much better. During testing, simple visual management methods were used track the testing progress. Here are a couple of pictures.
 |
| Testing - Daily Production Board |
 |
| Example of testcases |
Issues raised on today's tests.
Backlog of testscripts to be done
Scripts with defects
Data objects "in use" and hence reserved for ongoing tests.
A visual plan with all milestones and activities was filling the wall. Progress or delays were immediately visible with green and red dots. The visual plan helped us to "see, learn and act together as a team".
 |
| Visual Plan for SAP roll-out |
 |
| Visual Plan detail - green = started / red = overdue / blank = not to be started yet. |
