A new enterprise system for your business: Dos and Don’ts – Part 2
As observed in part one of this series, our business world is changing, at times much faster than we want to admit. In the past, it was possible to close off your business systems from the rest of the world. The internet has put an end to that reality; the days of a business working within a closed system are long gone. We now have a plethora of innovative systems, development methods and system vendors to choose from for your enterprise system needs. The question for business leaders is this: When the time comes for you to transition your business systems will you be comfortable with your decisions? (1)
One of most common oversights is that even though a business may recognize the need to upgrade their systems, their approach isn’t forward looking. We buy equipment based upon business growth and customer demand. We ought to use the same approach when it comes to our systems and ensure our assumptions about the future are appropriate. The evolution of enterprise systems (2) has been driven by the recognition that improved data-driven decision making is based on the capture of quality data to improve information access and knowledge development. Information, like other company assets, has immense value when properly deployed, safeguarded and maintained.
Last month we looked at planning for what the company needs in the future, e.g. tying business strategy with systems strategy and developing requirements. This month we will look at designing the system to support the new systems strategy.
“Unfortunately, we often build our business systems the way we build our cities: over time, without a plan, on top of ruins.”
Caution: Avoid recreating your current situation with new systems. Let’s say as part of your system strategy you decide to buy multiple systems from different vendors in an effort to mirror your current system architecture*. That is, you buy an off the shelf accounting system from vendor “A” to replace the out of date accounting software you currently use. Next, you select a customer relationship management (CRM) system from vendor “B” to replace the set of customer and sales spreadsheets that your business has accumulated over time. To address product configuration you buy a ready-made product configurator from vendor “C”. And on it goes. You replace each major system component in your business with outsourced systems without questioning the assumptions underlying your current system architecture. System architecture is a function of organizational design, so without a clear vision of what your company will need, and customers demand, in the future it is difficult to make valid system decisions. This results in the incremental ‘cut and paste’ approach all too common in transformation efforts. Building the ‘new’ over the top of the old without a plan often results in the waste of time, effort and resources.
*Architecture in a systems sense is the explicit representation of the strategy that underlies the arrangement of components in your enterprise system(s) and how they are organized and integrated to support your future needs. If there is no clear vision and plan for how your system supports your future state then, as often happens by default, your current state will most likely becomes the model for the future.
I observed a company close to the end of their years long enterprise systems update journey. They were justifiably proud of a decades-long technology legacy where their talented and long-tenured team created custom applications to fit every business silo need. The leadership, seemingly without a clear business or systems strategy, carried forward their current system architecture (unique applications for each functional silo) by purchasing multiple disparate applications from respectively unique vendors. At the same time old habits die hard and the purchased systems underwent modification. As a result, a challenging systems environment slowly evolved over time, without a clear plan, on the top of the ruins of past systems. The new systems retained enough uniqueness so that data collection efforts relied upon data warehousing approaches reflecting the system architecture of the past. As a result, three important aspects of system architecture were neglected:
- Single Source of Truth. SSoT means that the data that you use to access information, create reports, and maintain business continuity comes from a single source. For example, in the current scenario there existed three unique sets of “customer” information residing in three newly implemented systems serving three different business silos. Without a SSoT framework data quality, standardization, relevance, and reliability are all compromised. Users who access customer information now had three unique “sources of truth”. The result was a problematic master data management situation that created by design, as conflict arose with each siloed business team claiming that their data was the “right” data.
- Security means that you can control access to system functionality and information by managing user and user group access. In this situation with multiple disparate systems in place, the effort required to identify, grant access to, and maintain security for all the systems inevitably became unwieldy. It is not hard to imagine how IT security staffing needs and the level of detailed tracking required for each disparate system would grow to become both onerous and unmanageable.
- Interoperability means that users can access and interact with quality information from a single point in a coordinated manner without excessive effort. One of the main benefits of improving systems is to streamline access to information that knowledge workers require to serve internal and external customers. Each time a user has to switch systems, there is lost time – and as Benjamin Franklin reminded us – “Time is Money”. When system users are placed in the difficult position of being required to use the ‘same’ information residing in multiple applications, they are not being set up for success.
The system strategy outlined above, also known as a “Menu” approach, is often applied in situations where business functions are siloed, operations are static and there is no strong sense of direction. In this dispersed environment, the theory is that by replicating the old systems with closely aligned new systems, limited user adjustments is required. The siloed business structure coupled with a legacy system mindset resulted in limited progress for information users. Also, because integration (both as a business and between systems) was not recognized as a priority from the start, the need to connect and communicate became apparent too late, resulting in time delays and cost overruns. The typical approach taken today by most businesses is a “Global” approach, where a single Enterprise Resource Planning (ERP) system is chosen based upon prioritized future business capabilities and well developed requirements reflecting those capabilities. ERP systems have evolved to support a variety of business approaches and a modern ERP is already integrated to use common data across system modules. As a result, system implementation focuses on configuration (NOT coding) to meet well-defined future needs based upon explicit requirements. With a modern ERP, common data and the SSoT framework is built in, security is simplified under a common system, and users are set up for success because consistent information access allows them to serve customers.
Countermeasure – Define your Architecture
Avoid the temptation to ‘cut and paste’ the new on top of the old. While the temptation to cut and paste from a “Menu” is great, and a comfortable option in the near term, in the long run it is fraught with errors, control problems and frustration. Your system architecture needs to support your future vision; so put that rear view mirror away and commit to moving forward with a modern system that integrates common data, centralized reporting and simplifies user interfaces, making work and access to information easy, accurate and reliable.
- See “Does Your Business Need an Enterprise Systems Strategy?”, in the January 2020 issue of the Southern Oregon Business Journal, https://southernoregonbusiness.com/does-your-business-need-an-enterprise-systems-strategy/
- Enterprise System: Application of complex software that encompasses and integrates business functions. Typically an Enterprise Resource Planning (ERP) System includes modules designed to address unique business functionality (i.e., reporting, sales management, accounting, inventory, production, human resources, materials planning, purchasing, customer service, etc.). Most systems comprise standard modules (“core functionality”) and optional modules to allow flexibility in addressing enterprise specific requirements. Modern systems allow for system configuration (not software coding) at the record, module and system level through the use of user defined data fields and field behavior, data tables and table relationships, user and group level security and access rules, interface management, and audit tracking capabilities.
© 2023 Praxis Analytics, All Rights Reserved
Jim Myers is the principal of Praxis Analytics, Incorporated and a trusted advisor to business leaders in their quest to transform intentions into results. With experience spanning over two decades, Jim worked in manufacturing, supply chain, customer service and maintenance management roles within markets ranging from capital equipment to aerospace and defense. As Associate Dean of the Atkinson Graduate School of Management at Willamette University Jim led projects that doubled capacity, automated planning/scheduling systems and integrated best practices into school operations. He has taught graduate courses in Operations and Information Technology, Strategy Alignment, and Project Management. A former Marine, Jim credits the USMC with teaching him the value of leadership, quality people, good systems, and mission accomplishment. Jim can be reached at firstname.lastname@example.org.