This is the first of several blog posts about working in an Agile way with ERP systems…
Most of the developers, testers, BA's, and managers I know have little, if any, awareness of ERP: Enterprise Resource Planning. These are the big software systems sold by SAP in particular, but also by Oracle, Microsoft, and others.
Strictly speaking, ERP is a specific application for planning and scheduling resources usually in manufacturing, but many in the industry use the term “ERP” as a generic shorthand for a whole host of large enterprise applications beside strict ERP: CRM (customer relationship management), financial accounting, payroll, human resources, asset management, logistics and supply chain management, and more.
Over time the big players tend to have swallowed the more successful ones, so Oracle now owns JD Edwards and Peoplesoft, Microsoft swallowed Great Plains and Navision, etc. The products tend to get recycled… but I digress.
While most developers can happily spend their entire career avoiding these packages, those that encounter them find two things. Firstly, they very pay well - exceptionally well in some cases. Second, these systems are all-embracing: the database is probably hidden well down, it may well be hierarchical rather than relational, and they usually come with their own language (SAP has ABAP and Microsoft X++)
Over the years I’ve touched a few of these systems, some of the big names, some of the smaller names, some of the “modern” systems and some so old they predate the ERP classification — anyone for Rocket? Or Comet?
This year I’ve had a chance to work for an extended period with a team using Microsoft Dynamics and attempting Agile and I think its worth a few comments, partly about the state of “Agile and ERP” but also about ERP in general.
In the next few blogs, I’m going to say something about my experiences. I want to talk about the common issues with these systems, not specific problems of one team or another. Here are a few of the key points:
- Stepping into the ERP world from the Agile world is like stepping back 20 years, or maybe 30.
- You can do Scrum in an ERP environment but it seems impossible to do XP, i.e. getting the technical practices to support your efforts does not seem possible.
- Testing and automated testing is only possible in very limited amounts, and it's an uphill challenge.
- Configuration is a form of programming but many people in the ERP space reject the idea that they are programming and therefore reject (or probably never knew) the engineering approaches that programmers (should) take.
- Systems Analysts are alive and well in the ERP world: such analysts are rarely found in development teams any more. The role has fractured in two, where some of the work has gone to Business Analysts and some to Architects and Senior Developers (or just “the team”).
- Release cycles are long and the monolithic nature of ERP systems means they resist attempts to reduce them. The monolithic nature bites these teams again and again.
- Culture: the culture that surrounds ERP systems is the antithesis of Agile culture. In part this is because only large corporates have ERP systems; Agile can work in the large corporates but it is more difficult, it can work in a corporate culture but it is more difficult, so in ERP you start off down two and then you add ERP culture.
Reverse Conway’s Law means that the organizations which develop in ERP systems themselves take on the attributes of the system, namely they are hierarchical and monolithic.
ERP systems and Agile is a big topic and I’ve plenty to say so I’m going to blast out a series of blogs in the next couple of weeks, they are all drafted so watch this space:
- Part 1: Agile & ERP? (this introduction)
- Part 2: The Good News -(practices) Agile & ERP
- Part 3: Culture problems - Agile & ERP
- part 4: The Bad News - Agile & ERP
- Part 5: Peroration - Agile & ERP