🧮ERP: Implementations (Part XVII: Taming the Monsters)

ERP Implementations Series

 

Given their extensive scope, duration, investment and complexity, ERP implementations are probably one of the most complex endeavors pursued by organizations. Moreover, they are often a matter of endurance with many junctions, skirts, turns, shortcuts, ups and downs, a continuous carousel in which the various issues tend to misbehave like little monsters, many of them haunting one’s dreams unexpectedly during and long after implementations.

Probably, the main drivers are the scale and mass of such projects as they touch all or most important aspects of organizations. Just consider the typical project done for a single department and multiply its complexity by a constant number representing the number of departments in scope. And the more one goes into details, the higher the complexity. To move forward the parties need to compromise, and as no one wants to do that, the discussions are prolonged, the discussions get personal, issues are escalated, and probably more negative effects can be met.

Tensions can be rooted in politics, in the friction between different goals, in the need to prioritize requirements, postponing or leaving things out of scope, or by pushing an agenda other parties don't agree with. Besides the typical constraints of projects, there’s the complexity of performing a huge amount of work within a limited period, time during which the resources must be available, the quality must match the expectations, and there are so many aspects to be considered!

Of course, not all implementations are like this, though each such project is a real exam of maturity for the people involved in it. Sometimes, it’s better to have people who care about the decisions made. On the opposite side, there are organizations that go almost blindly with the solutions suggested to them, with all the effects resulting from this. Probably, the middle way between these two extremes is more indicated, though it’s hard to find such a path through all complexity.

An ERP implementation is highly dependent on the initial conditions under which the project has started, the commitment made by the various parties involved in the project, the way resources are made available, on what’s considered in plan, on the communication that takes place, the planning done and its enforcement, etc. Of course, some topics can be addressed also later, though delays tend to create more delays that can have a ripple effect through the project. Under normal circumstances the backlog and other aspects can be manageable, though it’s enough for a few issues to gather momentum so that their cumulative impact can have an exponential impact.

Certain sensitive project topics can easily lead to crises and abnormal behavior, though such situations are usually exceptions (until they are not). It’s important to have in place the processes and procedures that can be used to address this kind of situation, and, not less important, have them communicated to the team. Moreover, it’s not necessary to reinvent the wheel - the processes defined in IT and project methodologies can be used and adapted for this purpose.

It's important to have in place all the processes, procedures and checkpoints needed to support the project. The people participating in a project should have some hands-on experience with them, including the exceptions (e.g. escalation procedures). It’s useful to have a mentor or some experienced person who can help with advice and even attend meetings and provide constructive feedback. Just having some awareness sessions with no feedback can be as dangerous as not having any training at all! It’s suboptimal to use the implementation itself as an environment for learning though in extremis this approach may work as well.

Previous Post <<||>> Next Post

🌁Software Engineering: Exception (Definitions)

"An error condition that will divert a program's flow of control to an exception handler or to the calling program. PL/SQL supports both built-in system exceptions and programmer-defined exceptions. Exceptions may be named or unnamed." (Bill Pribyl & Steven Feuerstein, "Learning Oracle PL/SQL", 2001)

"An object that is passed from the area of code where a problem occurs to the part of the code that is going to handle the problem." (Jesse Liberty, "Sams Teach Yourself C++ in 24 Hours" 3rd Ed., 2001)

"A runtime error-reporting mechanism that requires programs to handle raised exceptions or have their stack unwound until each exception is handled (caught) or the thread terminates." (Damien Watkins et al, "Programming in the .NET Environment", 2002)

"Allows you to catch and manage runtime and other errors while programming. Managed with rescue, ensure, and raise. Compare with error." (Michael Fitzgerald, "Learning Ruby", 2007)

"a condition that violates one or more preconditional invariants; a kind of event sent to indicate such a violation." (Bruce P Douglass, "Real-Time Agility: The Harmony/ESW Method for Real-Time and Embedded Systems Development", 2009)

"Object that represents some kind of error such as an attempt to divide by zero or an attempt to parse a string that has an invalid format." (Rod Stephens, "Stephens' Visual Basic® Programming 24-Hour Trainer", 2011)

"A fancy term for an error." (Jon Orwant et al, "Programming Perl" 4th Ed., 2012)

"A condition or event that cannot be handled by a normal process." (IBM, "Informix Servers 12.1", 2014)

"An error that prevents the program from continuing unless handled by the software." (Matt Telles, "Beginning Programming", 2014)

"An unexpected condition in a program such as a divide by zero or trying to access a missing file. If the code doesn’t catch and handle the exception, the program crashes." (Rod Stephens, "Beginning Software Engineering", 2015)

"Associated with an unusual, sometimes unpredictable event, detectable by software or hardware, which requires special processing; the event may or may not be erroneous" (Nell Dale et al, "Object-Oriented Data Structures Using Java" 4th Ed., 2016)

"A signal that some unexpected condition has occurred in the program. In Java, exceptions are objects that are subclasses of Exception or Error (which themselves are subclasses of Throwable). Exceptions in Java are “raised” with the throw keyword and handled with the catch keyword. See also catch, throw, and throws." (Daniel Leuck et al, "Learning Java" 5th Ed., 2020)

🌁Software Engineering: Exception Handling (Definitions)

"The way a program responds to an error. The exception-handling mechanism in Perl is the eval operator." (Jon Orwant et al, "Programming Perl" 4th Ed., 2012)

"Behavior of a component or system in response to wrong input, from either a human user or another component or system, or due to an internal failure." (Tilo Linz et al, "Software Testing Foundations" 4th Ed., 2014)

"The performance of a specified response to an abnormal condition. Exception handling allows control and information to be passed to an exception handler when an exception occurs." (IBM, "Informix Servers 12.1", 2014)

"Behavior of a component or system in response to erroneous input, from either a human user or from another component or system, or to an internal failure." (IQBBA)