In my first post, I had introduced the Circular Economy (CE). The core idea was an argument to support the deployment of a new PLM application along side your legacy business applications, which arguably handle a variety of business activities, with the aim to extend the usefulness of these applications (and increase their overall ROI, hopefully). The concept of CE embodies all kinds of concepts I'm sure you're familiar with - such as closed-loop processes, continuous improvement, iterative processes, etc. The idea, let's not forget, is to encourage sustainable design. This implies designing with lower environmental impact and planning for extending the life spans of created widgets and software.
A good, long-time friend from college reminded me of how odd it appeared that R2-D2, a repair/jack-of-all-trade droid from the popular Star Wars movie franchise, would have such a long life span, while his personal desktop computer had to be replaced every 3 years or so. An article in the Economist of June 28th 2012 ("Trucks, not limos", paid content, my apologies) makes the same point, stating the US military is concerned about having simple platforms like "trucks, with plenty of space and power to accommodate different payloads" - ie, electronic gadgets and payload that evolve as technology progresses. An example given was the B-52 bomber, conceived already more than 60 years ago, which evolved from a platform to launch both "dumb" bombs and nuclear weapons to smart weapons as well as cruise missiles.
In the industry, the need to develop sustainable infrastructures and data models exists as well, as businesses are under pressure to improve efficiency out of existing processes and resources, increasing margins in places that seem to have been "maxed out". In digital business processes, inefficiencies such as
...translate quickly into user frustrations - a tangible outcome being user rejection or the bypass of established processes. Eventually, an enterprise deploys either quick fixes, through policing processes, or looks hard into what's fundamentally wrong with the picture. The worst case scenario that is drawn up is about structural change - introduce a completely new process that involves retraining your workforce to support it.
We know the technical aspects of re-engineering a process is usually well defined: it includes the cost of additional software and supporting hardware, and its ancillary services to implement it. What is often intangible is the workforce behavior. In order to gain support from the user base for any process or software, and reduce their production interruption, it is imperative to limit the introduction of interfaces they need to be trained on. Enter: back end processes (BEP).
BEPs do the grunt work of integrating discipline silos, arduously capturing & converting data and automating event messaging. Sounds like concepts from Enterprise Relationship Management (ERM)? It is because BEPs aim to improve the business by herding all these cats, through an Enterprise Service Bus (ESB), an Internet Service Bus (ISB, for applications that are hosted "in the cloud" or merely through a web application server) and/or Open Services for Lifecycle Collaboration (OSLC). All these activities happen within an EDM framework. This allows for a business document to be owned by different authors as it proceeds in the business object's life cycle, and shared along the way with its stakeholders.
You might have caught I introduced the notion of business object distinctly from business document. Digitizing the enterprise allows you to break down the paper processes you have, where at any given time a document is owned by a single person in the process and is made available only upon review at meetings, or shared through copies.
EDM is therefore more than a glorified vault for MS Office documents, or a variation of Google Docs.
Becoming a digital enterprise does not necessarily mean becoming an enterprise that provides web-rich contents, or intends to challenge Rovio (of Angry Birds fame). Many staid businesses (such as Skanska, a large Swedish construction group, Cemex, a Mexican cement manufacturing company and McCain, a Canadian food processor) adopted various forms of EDMs as a way to organize their data and collaborate across geographies and various disciplines, thus providing more timely information upon which decisions are made.
One of the benefits of achieving EDM is it facilitates the reuse of the business data you have gathered through the years. Let's not kid ourselves: frequently, a "Brand New" product involves cosmetic changes or partial contents changes to improve the cost structure, or necessary changes as a response to customer requirements, and is usually based off existing contents, knowledge and processes.
If this seems a bit too much to take in a single serving, keep in mind EDM is a journey, not a destination. The implementation of a converged solution that allows all your silos to communicate at given events is not an overnight project. For that journey, you'll need travel companions:
You'll notice I have put both pros and cons for any of these roles: while anyone might want to be a 'Visionary' or an 'Executor', these are actually big shoes to fill. Ask yourself: Do you want to be the one responsible for this task? Can you articulate the vision and sustain the interest? Will you be able to sleep soundly at night? Can you defend your position amid intense criticism?
Process profiling is a tool that allows you to assess the frequency a process is invoked in your business operations. It should reveal dependencies against other processes, with the aim to identify bottlenecks and map your cost structure. The outcome of this activity leads to data profiling (see, the 'Data' part of EDM appears again).
With your team identified and provisioned, set up your processes through a priority matrix. Highlight the 20% of your processes that impact 80% of your activities, through process profiling & normalization. For instance, your profile reports could reveal bottlenecks in:
Normalization allows you to identify the relative value of processes against each other. The goals are to:
Fig. 1 Cadillac bumper assemblies - '91 (left), '92 (right), showing design change that reduces the amount of work to set up the bumper - The Henry Ford museum, Dearborn, MI.
Automotive OEMs frequently go through this exercise, as Figure 1 shows. Within 2 model years, design improvements reduced tremendously the amount of fasteners involved, simplifying the installation of the part. Of course, we understand some of the improvement is offset by new tooling and process change. While the above is a physical process improvement, similar digital (virtual?) process improvements exist - they are just not as dramatic.
EDM is a strategy that is supported through a combination of ESB, ISB and OSLC processes, and some form of data platform or data hub. It allows you to re-use data across projects. We'll explore more soon - hopefully, with less TLAs.
Stay tuned!
(All views expressed in this blog are my personal views and do not belong to any group/organization I belong to. The blog may contain some data which may not have been verified by me. The blogger is not to be held responsible for any misrepresentation of facts, or data inconsistency. Abbreviations are used to lighten the reading - I don't intend to invent TLAs. Finally, all trademarks and registered trademarks are the property of their respective owners.)