Enterprise software, especially Product Lifecycle Management (PLM) Enterprise Resource Planning (ERP) is complex both from a functionality and integration perspective. Whether such software must necessarily be complex is a topic for another time. Success in any Enterprise software implementation often requires dedicated resources, careful planning, technical expertise, executive sponsorship, and a receptive culture, among other things. Sometimes the results of such efforts are transformational, producing both measurable and significant business benefit. In other instances, however, enterprise software implementation attempts can and do fail, due to a variety of possible factors. My last post regarding PLM Startups instigated a bit of unexpected controversy with regard to PLM failure. In case you’re not up to speed catch yourself up with the last post here: Why We Need More PLM Epic Fails. The point of controversy, surprisingly, is contention about whether PLM failure exists at all. Despite the fact that all other Enterprise software implementation is known to fail, is PLM somehow –perhaps magically- immune?
At the heart of any enterprise system, be it Product Lifecycle Management (PLM), Enterprise Content Management (ECM), or Enterprise Resource Planning (ERP), beats the steady pulse of change management. Truly understanding the evolution of any complex system necessitates some form of change methodology. It’s interesting though, that outside of engineering/manufacturing circles, change management in of itself seems relatively unknown. Even mention the term change management outside this realm of expertise, and the first reaction typically is “Oh, you must mean organizational change management.” Qualify the term as engineering change management or document/asset change management especially and (with a few exceptions) it’s generally a world of deer and headlights. Alarmingly, it seems the tenets of change management are to be forever confined to the a world of engineering complexity, not because of their lack of relevance but perhaps their lack of accessibility. In contrast, witness the explosion of web applications that focus on real-time co-editing of content, sacrificing structure for immediacy. As the pace of business accelerates, there is mounting pressure to adopt those immediate models. Is this the death of change management?
Attempting to predict the often promised Google enterprise revolution has become somewhat of a enigma on the internet for some time. Not a day passes without at least one tech blog or another building on the energy of a particular Google technology, suggesting that perhaps tomorrow, or possibly next week, or maybe even later this year (or is it next?), Google will finally make significant inroads into the enterprise market. I feel a great disturbance… as if a million people were collectively holding their breath, and suddenly exhaled. Often cited as Google’s entry points into the enterprise are underground tool adoption by way of Shadow IT or the legitimization of BYOD. These points of entry are often touted as the means to allow Google magic to sweep into the long-beleaguered enterprise and issue a new renaissance in collaboration technology. But the entire concept of Google successfully disrupting the enterprise is caught in a warp bubble; it’s just not going to happen. Google in the enterprise is the equivalent of a young, eager, rainbow-shirted Wesley Crusher, brilliant at discovering and using technology, but totally uninterested in the customer.
The constant rush to ram the perceived collaboration advantages of social networks down the collective throats of the enterprise continues relatively unabated, even despite mounting evidence that Palpatine has no clothes. Previously in Antisocial Enterprise and Antisocial Enterprise II I’ve discussed how the social networking model by its very nature is fundamentally misaligned to business needs, and that dumping such technology into the fray stands to be even more disappointing than Sharepoint. While users scramble for the nearest airlock, many architects and analysts are wondering how to tweak the technology and integration to operate effectively in the business realm. But the answer is not forthcoming. The problem is well beyond understanding how we interact with social networks, but also precisely what those networks do to us. The underlying problem in fact is not technological, but rather sociological. We have met the enemy and he is us.
There’s a growing divide lurking in the heart of today’s system of systems product development, as system complexity continues to steadily increase. Left uncorrected, the dysfunction stands to topple some of the most elaborate (and colossally expensive) enterprise software solutions to date by rendering their perceived benefits moot. All those nice, warm promises of accelerated time to market and improved execution might get tossed right out the nearest window. What could possibly do such a thing? Some kind of inter-dimensional space-potato-monster thing? Ben Affleck Batman? No, the truth is less horrifying but equally devastating: it’s the growing digital divide between hardware and software development, between Product Lifecycle Management (PLM) and Software source control.
It was the best of times, it was the worst of times… 2013 was like that for the cloud. As the increasingly intimidating list of United States domestic spying allegations continues to mount, cases of second thoughts in Cloud City are rising. The seemingly unstoppable revolution toward global data accessibility is now facing the same obstacle that has hampered ownership and non-digital interchange since forever: national borders. With the Sarlacc’s share of cloud providers in the very same country plagued with the most disturbing revelations about the illusion of data security, there’s a bit of a problem. Not surprisingly, the Lando’s of information enterprises are decrying that was never a condition of our agreement. So far, the response has been more or less expected. Perhaps you think you’re being treated unfairly?
Epic failure. The source of all life. No human, dog, or software technology is immune to it; it is a great equalizer and also a great teacher. Sometimes failure is entirely unexpected, wrecking havoc on the best laid plans and contingencies. Other times you can clearly see failure, like Visigoths strolling over the seventh hill, fully three-fifths as angry as disaffected enterprise software users, determined to make the most unpleasant Wednesday in Rome ever. Whenever someone, somewhere tries to stand on a bicycle, vote for competent government representation, or implement monolithic enterprise software solutions, failure is waiting just around the corner ready to deliver a friendly nudge back to planet reality.
Managing the implementation of enterprise software is an often daunting, humbling, and formidable task. As I detailed in The PLM Trail, perhaps too much so, though it’s not limited to just Product Lifecycle Management (PLM). Managing the technology, the organizational change management, the politics, the angry dinosaurs, it’s enough to generate the same fear that would take the heart of me. The path forward is often obscure, replete with difficult decisions and imminent peril. And so it is that many appointed with such a task, lacking a functioning palantír or other assorted prophetic magical crap, resort to a much more practical tactic. Yes, the tried and true technique of when in doubt, ask your neighbor; otherwise known in business terms as customer references. Such interactions are sure to provide a wealth of so-called best practice, and while some of it might be a little perplexing, at least all the kids at school are doing it!