Business management software is not a panacea that will instantly improve an integration business. Integrators must establish processes for every aspect of their business, including proposal creation, installation, procurement of materials, scheduling and service. Only after those processes are in place can the implementation of a software solution be most effective. In a panel discussion at CEDIA Expo, Chris Smith, principal at consulting firm TheCoTeam, and Randy Stearns, CEO of D-Tools, outlined how to take a modular approach for each area of the operation to build processes and make them “stick” with the team. They also addressed how using an outside consultant can assist.
“From a process standpoint, integration companies essentially all do the same thing. All the processes are common. There is always a sales process, a design process and a proposal process. And integrators all go through the same phases of installation, including the purchasing of materials and scheduling the required resources. So the process is the process,” says Stearns. He recommends integrators seek out an industry consultant, such as Jason Sayen of IAmSayen, who specializes in helping integrators establish their internal processes. Once those are in place, Stearns says industry-specific software like D-Tools is designed to follow a company’s business process.
Stearns cites defining the individual roles within an organization as one of the most important processes to establish, but it is often overlooked. With defined job roles in place, an integration company can better determine which particular modules of the industry-specific software those staff members will be utilizing.
For example, if they're a salesperson, they're going to be involved in using the estimating and quoting module. If they're a project manager, they're going to be using the scheduling and purchasing element of the software. If they are in materials management, they are going to handle inventory accounting.
“So, the software is role specific,” adds Stearns.
Smith agrees, noting that by looking at each individual module of the industry-specific software, an integration company can better determine which person within the organization should take ownership of that process. For example, within the software there is a sales module, a CRM module, a purchasing module and a time-tracking module.
“Somebody needs to take ownership of the deployment of those modules to the respective parties,” advises Smith.
But the process doesn’t stop there. Smith recommends that whenever a particular process or software module is deployed, it needs to be closely monitored for at least 30 days to ensure it is gaining traction within the organization.
“The software module or update is actually at its most fragile within that first 30 days,” he says, recommending that integrators designate someone on the team to manage the deployment, just in the same way there might assign a project manager to an installation.
“Doing that correctly enables those modules to dovetail nicely into each other. There are some things that absolutely need to be done before others. And there's some things that might need to be deployed concurrently across teams. Having somebody come in and help you do that, or having a person who comprehends that within your organization, will be the difference between a successful software deployment and implementation or one that feels like an absolute nightmare. And that is true no matter which brand of software you pick,” he says.
Internal Handoffs Are Key
Beyond just having the defined roles of each staff member in place, Smith says it is also vital to have clearly defined handoffs between departments and team members.
“Where do the handoffs happen between humans? We might call one person in your team a project manager, but he or she might also have an engineering component in their job. We might call someone a salesperson, but they have project management responsibilities. The handoff that's happening throughout the software process needs to be well-defined,” asserts Smith.
Those handoffs should be specifically delineated to avoid confusion… all the way down to indicating which person on the team clicks a certain button in the software, advises Smith.
