ERP and all That

Been looking at how ERP can utilize AI and RPA so this was of interest.  Interesting piece though   over acronymed.

Software Delivery Management: ERP for IT redux? in Forrester
by Charles Betz, Principal Analyst

" .... Software Delivery Management helps organizations streamline CI/CD processes and foster meaningful collaboration across all functions involved in software development and delivery. Its purpose is to increase software delivery velocity, quality, predictability and value which consequently results in improved customer and user satisfaction and better business results.

Seems like a reasonable set of goals. SDM as CloudBees describes it is similar to Value Stream Management (VSM) as my colleagues Chris Condo and Diego Lo Giudice have framed it. However, CloudBees really caught my attention when in (on-the-record) briefings for analysts, they compared their SDM vision to Enterprise Resource Planning (ERP) vendor SAP.

SAP? This might be surprising to many in the DevOps community. However, it makes perfect sense to me.

I’ve long wondered: most of the C-suite is well served by ERP vendors like SAP and Oracle. Why not the CIOs of the world? Why are their tools so fragmented? Why does the cobbler go barefoot? It’s not a new question (I wrote a book about it), nor a new branding idea. Various IT service management (ITSM) vendors have experimented with “ERP for IT” messaging, but didn’t get much traction. Why not? And what might be different with SDM?

I think the biggest problem for the ITSM vendors is that they were starting at the end of the digital value stream, at the phase of operations and support, when the harder and more valuable aspect is upstream, in software development.

Before continuous delivery, upstream was a world of project management where (oftentimes) the build and deploy toolchains were unique to each project. Now, the industry has a solidifying vision for a continuous delivery conceptual architecture that spans projects (which are increasingly turning into steady-state products[i]). Story, commit, build, package, provision, deploy, operate – the deepening, DevOps-driven industry consensus here is is a big step forward, and might well be “what’s different this time around.”   ... "



I think the biggest problem for the ITSM vendors is that they were starting at the end of the digital value stream, at the phase of operations and support, when the harder and more valuable aspect is upstream, in software development.

Before continuous delivery, upstream was a world of project management where (oftentimes) the build and deploy toolchains were unique to each project. Now, the industry has a solidifying vision for a continuous delivery conceptual architecture that spans projects (which are increasingly turning into steady-state products[i]). Story, commit, build, package, provision, deploy, operate – the deepening, DevOps-driven industry consensus here is is a big step forward, and might well be “what’s different this time around.”

However, what can we do with this consolidated “digital supply chain” data? Magic does not happen just because we have the data integrated into a common repository. This is cargo cult thinking. We need clear use cases. ERP systems, and their MRP (Materials Requirements Planning) predecessors, have great clarity of purpose – reducing inventory carrying costs by significant factors through better order scheduling, for example. SDM needs to further articulate such benefits.

Can we decrease inventory (i.e. the invisible inventory of “design in process,” as Don Reinertsen has called it[ii])? Better and more quickly identify constraints and bottlenecks, such as not having the enough of the right skills at the right time? Increase speed to market? Prune product options more quickly? Increase our speed of learning? Decrease operational or change risk? Restore service more quickly? How does the availability of this new information achieve these value propositions? Can we make an economic case for it?

It seems like there ought to be value there. But “seems like there ought to be” is not a business case, and clarifying that line of sight to value I think is a priority. My current hypothesis is that we are going to make more headway by building simulations, rather than trying to solve the digital pipeline’s problems analytically.

Are you starting to explore the frontiers of what big data, analytics, machine learning, and simulations can tell you about your digital delivery pipeline, from idea to operations? If so, please drop me a line.

Disclaimer: I don’t recommend “ERP for IT” as either an internal or external brand. It remains a useful and provocative thought experiment, however.

[i] Kersten, M. (2019). Project to product : how to survive and thrive in the age of digital disruption with the flow framework. Portland, OR: IT Revolution Press.

[ii] Reinertsen, D. G. (1997). Managing the design factory: a product developer’s toolkit. New York ; London: Free Press., p.11.