Seeking agility in Bimodal PLM
The need for greater speed and agility to keep pace with the evolving digital landscape has also hit the bimodal PLM sphere. Digitalization has led to competition that challenges traditional PLM applications and project implementation methods.
Product data is usually managed using large, traditional systems, with myriad methods and processes that require rigorous development and testing methodologies.
Established core systems can’t move fast enough to handle the rapid pace of changing technology and customer needs. Most traditional PLM processes and systems are not designed for speed and agility.
This lack of versatile and flexible applications and processing ability has led organizations to seek PLM agility via ”Bimodal IT”.
The rise of bimodal IT
The term Bimodal IT was coined in 2014 by Gartner, which defines it as:
“… the practice of managing two separate, coherent modes of IT delivery, one focused on stability and the other on agility. Mode 1 is traditional and sequential, emphasizing safety and accuracy. Mode 2 is exploratory and nonlinear, emphasizing agility and speed. Bimodal IT is the only sustainable solution for businesses in an increasingly disruptive digital world.”
Bimodal is the practice of managing two separate but coherent delivery modes:
- Mode 1focuses on predictability; its primary objective is to keep the business going.
- Mode 2concentrates on exploration and targets innovation, experimentation and learning.
Bimodal PLM differentiates an organization’s traditional IT, which calls for deliberate stability and care, with innovation and digital customer-facing capabilities that require agility and speed.
Enabling experimentation with Mode 2
Bimodal IT enables organizations to test new technologies without risking business continuity. It calls for two distinct teams with well-defined areas of priority and focus. The “Mode 1 team” ensures that core systems run effectively and efficiently, which gives the “Mode 2 team” space to work on innovative and user-centric solutions that increase engagement and provide quick business value.
The key aspects of enabling experimentation through Mode 2 are:
- Experimentation and learning
An organization driving innovation must be able to experiment with new ideas, new features, new user experiences, new business models, and new technologies and incorporate learning as a core value in the team’s culture.
- Customer-centric design
A focus on business outcomes, where the goal is to ensure that you are building the right product, by continuously validating the product’s vision with users
- Agile development and DevOps
Mode 2 pillars are agile and DevOps methodologies, which anticipate the need for collaboration between development and operations, and are grounded in flexibility and pragmatism in the delivery of a product.
- Cloud application and infrastructure design
Unknown scale requirements demand an elastic infrastructure. Cloud technologies enable flexibility in how apps are built, delivered, and managed, and usually yield business outcomes more quickly.
Potential drawbacks of “going bimodal”
While having an innovation lab in your IT organization might sound like a great idea, the bimodal approach introduces several challenges.
1. It can build a wall of confusion between IT groups
This dual-mode process may introduce a breakdown in communication and can potentially quickly build a troublesome wall between IT groups competing for funding, resources and, most importantly, attention.
2. Mode 1 may slow down Mode 2
There are lots of dependencies between user-focused solutions and traditional core systems. Usually projects running on Mode 2 require development of traditional systems, too. Making data and functionality available from core applications or creating a change request for master data are just two examples of the collaboration that may be required between Mode 1 and Mode 2. Mode 1 traditionally follows a rigid release cycle, and any planned changes need to be included in the plans. It’s important to get organised beforehand and reserve adequate resources on the core-systems side to make it work.
3. Failure to achieve long-lasting change
It’s easy to focus on developing innovative technologies, but don’t forget that development is just part of the equation. Working on a project end-to-end, developing and implementing processes and training the organization is just as important as creating a shiny new tool. Don’t ignore change management, and make sure there’s a proper handover to the people responsible for keeping the lights on.
4. Decreasing motivation in the Mode 1 team
Employees will probably quickly label Mode 1 as “boring” and Mode 2 as “exciting.” Some may not want to work on Mode 1 because of a perception that taking care of traditional applications is not as cool as building new things. That creates a dangerous culture that could lead to the Mode 1 team members becoming unmotivated and looking at the exit door.
Towards an end-to-end multi-speed IT
Is bimodal the path to help companies shed the lethargy associated with rigorously documented and monolithic PLM systems? Critics argue that deliberately bypassing established processes and teams to get things done might not be the right way to address the need for speed.
According to Forrester Research, Bimodal IT may provide some relief for CIOs in the short term, but it is not a strategy for long-term success. In a world where we are trying to break down silos, building a wall between the “innovative and fast” and the “legacy and slow” is probably not a long-term solution: it’s too rigid, and oversimplifies the solution to the real problem.
Learn from the experience of the chief digital officer at GE Digital, Bill Ruh. He’s run several projects on bimodal PLM and has concluded that to be a truly digital company, bringing together all digital capabilities under one group is the only way to make it work.
Some advocate for an evolution of bimodal, multi-speed IT. The core principle of multi-speed IT is to enable multiple delivery pipelines to support the various speeds and technology platforms that business requires.
Even supporters of this approach call for coordination across delivery pipelines. Identifying and understanding the architectural dependencies between the various projects executed by different teams is essential to ensure that the delivery and release of each application and innovation project is coordinated.
[thrive_leads id=’4394′]
