Last week I participated in Electric Cloud’s Continuous Discussions (#c9d9) podcast. It was a great discussion about value stream mapping. This topic is highly applicable to the Oracle JD Edwards EnterpriseOne customer base. I’ve included a link to the podcast here: http://electric-cloud.com/blog/2017/02/continuous-discussions-c9d9-podcast-episode-63-value-stream-mapping-devops/
Here are some key takeaways from the talk:
Why is Value Stream Mapping Important?
In general value stream mapping breaks apart the concept of complexity and what is complicated. Value stream mapping compartmentalizes processes in an easy to understand organizational model. In DevOps and using value stream mapping, we see our customer base moving away from simply removing waste to new orders of value creation.
From a DevOps perspective who is involved when you do value stream mapping and why do you do it? what and why you do this for your customers?
At AutoDeploy we build the mapping process into our software and our engagement with our customers. We want to make the experience as frictionless and as easy to adopt as possible. We ask for information about current state, the dimensions of the customer’s Oracle installation, and collaboratively work with the customer to develop a new state. We want customers to think about how they are delivering their artifacts and information into production.
Documenting the current and future state is critical. The end to end process of delivering change to production must be flexible. Some customers have a well defined process in place and we want to be able to plug into their existing model and let our software loose. Other customers benefit from thinking about their existing processes and areas that they can improve.
The importance of documenting the value stream is in helping customers understand who is involved in a specific step of the process, why that person is involved, and the value that each step brings in delivering change to production.
Working with our customers we create a broad document that is easily consumable. Our end goal is to deliver software that enables change to be delivered in a repeatable and high quality manner. Seeing how that process is reflected in a value stream map provides enormous value across an organization.
The documentation process provides an opportunity to find areas of hidden value and opportunities to discover areas for continuous improvement. Value stream mapping is broadly applicable. It is important to have communications processes built into every step of the value stream map and it should be an automated communication step. At AutoDeploy we believe computers are better at handling rote / repetitive tasks. Let’s offload that work and let people be imaginative and creative to deliver new value to the business.
We speak a lot about how flexibility of process is key. Speeding up the change management process is great, but increasing speed at the cost of quality can create negative unintended consequences. Deploying 25 times a day in dev is vastly different than deploying to production. AutoDeploy provides the framework for a business to find its’ deployment cadence. The software is flexible enough to meet any deployment clock speed
How do you get started with info, people, ready for customers?
We have a three step process — internally we map out the customers installation process. An engagement manager talks to the customer about their existing process, we have the customer run some canned reports on the topology of the installation, we then meet internally to ensure everything aligns to the customer’s objectives, and we document the current state and future state. We treat the documentation process as very flexible to deliver maximum value to the customer. AutoDeploy does not want to deliver software to our customers and say, “good luck.” We work with our customers on every step of the installation process. Most people can get overwhelmed thinking about an installation, and this is understandable. Realistically the entire installation, documentation and delivery of the AutoDeploy suite takes about 4 hours. I think that our time to value is exceptional because we’ve mapped out, internally, and asked ourselves how we would want software to be delivered?
