What exactly is technical debt? When discussing your organization’s technical debt - and possible changes to it - with various audiences, you need to articulate the key issues in plain terms. Here’s expert advice on how to do that.
Digital transformation success: 5 takeaways from MIT Sloan experts
Not all of us can be digital natives. A new book by Jeanne Ross shares digital transformation lessons from older companies rethinking product offerings, process, and technology
Dr. Jeanne W. Ross, principal research scientist, MIT Sloan School of Management's Center for Information Systems Research.
Sick of being told your business should be more like Apple, Amazon, Uber, or Airbnb? Mystified about how to apply their examples to your big, older company’s digital transformation work?
If so, read Designed for Digital: How to Architect Your Business for Sustained Success, the new MIT Press book by Jeanne W. Ross, Cynthia M. Beath, and Martin Mocker.
Ross is a principal research scientist with MIT Sloan’s Center for Information Systems Research, and her collaborators worked with her to distill the findings from five years of research, including surveys of hundreds of business and IT leaders and case studies of dozens of companies.
They found most of those companies were very early in their journey to any kind of true digital transformation of their business. Yet they did find examples of big, established companies that are making significant progress toward figuring out how to create digital offerings, including DBS Bank, LEGO, Philips, Schneider Electric, and USAA.
[ Culture change is the hardest part of digital transformation. Get the digital transformation eBook: Teaching an elephant to dance. ]
When the book addresses digital native companies like Amazon, it’s often to point out that they were not born as fully realized digital platforms. Amazon’s very early business model was built around fulfilling book orders transmitted by email. What makes the company remarkable is how well it has adapted to and capitalized on waves of technology from web commerce to cloud.
Consider the book’s key takeaways:
1. Your business needs a digital design
Instead of trying to be Amazon, your organization should be figuring out how to continue to do what it does well and add digital products that enhance its products and services, Ross writes. You need to decide how best to exploit social, mobile, analytics, cloud, and the Internet of Things – what Ross calls SMACIT (pronounced “smack it,” as in what you do to your head when you realize how overwhelming it all is).
To whittle the possibilities down to what makes sense for your business, you need a design for your business – one that probably does not exist.
This is a central thesis: “You might think that CEOs, CIOs, and other C-suite leaders have always assumed responsibility for business design. Think again. Rather than design their companies, most business leaders structure them. They created high-level structures that relegate to lower organizational levels the responsibility for figuring out how things get done.”
When that structure isn’t working, an organization may reorganize or add matrix reporting structures – without making the organization any more agile, the authors write. “The problem is that – given their seamlessness – digital offerings require a fast cycle of decisions and actions across functional and business line silos. As siloed companies attempt to deliver digital customer offerings, a growing number of decisions are referred up the hierarchy, discussed across silos, and then communicated back to where action will be taken.”
The point is not that you must wipe all departmental structures away, but that an agile, digital organization must be more distributed. “The accountability framework for digital devolves many decision rights to autonomous teams while creating the context to help these teams make the right decisions,” the authors write.
[ Read also: Digital vs. digitized: Why CIOs must help companies do both, by Jeanne W. Ross. ]
2. IT architecture is important, but not the point
Some other books in this category – particularly those written by marketing experts – overstate the case that digital transformation is all about business strategy and has little to do with technology. Ross and her coauthors spend more time describing a generalized architecture for digital transformation. However, the point is not to design an elegant digital system that will impress other IT architects but to use technology to create business opportunities.
“Without digital (re)design, any new technology will, at best, improve how companies do what they’ve always done,” the authors write.
That is, in the same way that reorganizations don’t necessarily produce a better company, reorganizing (or integrating) data systems will not necessarily achieve results unless they are part of a broader design.
3. A robust operational backbone is necessary but not sufficient
In sketching the technological underpinnings for transformation, the authors distinguish between the operational backbone and the digital platform.
The operational backbone consists of core systems for operational efficiency, including ERP, supply chain, and CRM systems, as well as foundational industry-specific systems like hospital electronic medical records systems. If your organization has been around a few decades, your operational backbone includes all the things you were supposed to have been integrating and optimizing all along.
The digital platform, on the other hand, includes the new technology needed to create digital products. Maybe your ERP vendor can sell you components, alongside the SMACIT technology specialists. But your digital platform will be more of your own creation, reflecting your business design.
Born-digital companies sometimes create a strong digital platform but neglect the operational backbone, which is just as big a mistake as not achieving much digital innovation. Both are necessary. However, one of the biggest reasons established companies give for not achieving greater digital innovation is that their operational systems are holding them back.
When is your operational backbone “good enough?” Let’s explore: