A Tale of Two Systems

A while ago an executive acquaintance was telling me about the challenges of integrating two service businesses that his company had acquired. His plan was to develop a combined venture that would provide broad geographic coverage under a single brand identity. Integrating service records across operations was vital to the success of the enterprise. The good news was that both companies had come into their new corporate home with the same records management system. The bad news was that one group was eager to promote it as a standard for the rest of the organization but the other was campaigning hard for a major investment in a new system.

My acquaintance knew that a major system project could easily absorb enough time and resources to interfere with other business development priorities. He asked me to look into the situation and help him understand what to do. Through a series of interviews with key individuals it became evident that both operations had similar resources to work with (30-40 employees with a single IT support person) and that both had received about the same amount of initial support from the vendor. After initial installation of the software the two had taken very different implementation pathways.

The “happy” group had taken what they had learned from the vendor and spent the next few months reorganizing their information around the capabilities of the software. They moved into production in stages, and during the entire time the General Manager met with the implementation team weekly in order to discuss problems they were experiencing and help them decide how to move forward. Six months into the implementation process they had absorbed the change to electronic record keeping and were looking for ways to expand use of the software.

The other group had moved rapidly into production with software that was populated with just enough information for people to replicate what they had been doing manually. Support work was delegated to the IT person with little ongoing management attention. By the time six month had passed the entire group was frustrated and hostile toward the system, convinced that it couldn’t work and were actively working at building custom workarounds.

Turning the situation around involved a team effort that brought together operational and IT staff from both organizations and the software vendor. We started by giving everyone an opportunity to learn more about what the software could do. This led to a decision by the group experiencing difficulty to reconfigure both the software and some of their work procedures so that the system supported their business processes more effectively.  As they began to experience some success the hostility diminished gradually and the combined group was able to make progress together in other areas of integrating services between the two operations.

That was more than a decade ago. It began a journey that has taken me through a host of business system design and implementation projects in different organizations and industry sectors. Those experiences have shown me that it’s rare to find software packages that can’t do what the vendors say they can. However, the benefits of adoption can be illusive because managers often don’t realize how much re-design of work practices is involved in implementing a new system. Successful project teams are usually the ones who  understand — and are equipped to deal with — the way that technology can change work.

The journey continues. The goal for this site is to provide a place for thoughtful discussion about how people use technology to get work done and to organize resources that people find useful.

Leave a Reply

Your email address will not be published. Required fields are marked *


*