To quote Mel Brooks as Louis XIV in “History of the World, Pt 1”: “You do It, I do It, we all do It.” In this case, process is the “it” that needs to be clearly defined before selecting tools to enable efficiency and productivity in an operations group. More often than not, groups look at software to address a technical and business need before they know how they’ll use it, the problem they are trying to address, and how the tool will blend with current processes and existing software.
Process
One of my undergrad majors was marketing. The key concept I took away from that coursework: someday you’ll buy something, not because you need it but because of marketing. Do we all need the latest and greatest gizmo we see or hear about? Of course not, yet many will buy it because of great marketing. I almost applied for a Capital One credit card because those marauding Vikings tried to convince me they might be in my wallet, yet Carl Malden’s convincing dialogue remains the one I “don’t leave home without”.
Vendors, good and bad, have a unique way of marketing and selling technology products based on customer relationships, reputation, support by industry experts, and/or my favorite: FUD – fear, uncertainly, doubt; what’s in your wallet? The problem is, until a group has succinctly spelled out the process they’ll follow, selecting a tool first is the vendor wagging the customer.
I can’t stress the importance of understanding your processes, and how they affect the organizations and dependencies around you. In the technology world, we are wrapped around software, servers, laptops, firewalls, switches, routers, load balancers, wireless devices, Blackberries, multiple operating systems, and a host of service level agreements just to name a few. Software tools are the stuff that keeps us running on the bleeding edge of success and failure.
Twenty years ago, a software failure wasn’t the end of the world. Today, with tight integration of systems and processes, OSS (operational support systems) becomes even more critical to an operations group than ever.
Know the process, be the process. Once you are one with your process, start the tool evaluation process.
The Wheel
The wheel wasn’t created looking for a problem to solve. It was discovered that the wheel addressed the process prehistoric man used for dragging their important stuff around. Not real technical; simple; short users’ guide; no government warnings like “CAUTION: KEEP FEET FROM UNDER WHEEL. COULD CAUSE LOSS OF FOOT AND LIFE AS WE DON’T KNOW ABOUT PENACILLIN OR MODERN MEDICINE.” The wheel complimented the process people used for moving items and they didn’t become slaves trying to maintain it.
If an application doesn’t compliment the business and technical requirements of the processes developed by an organization, it becomes:
1) a burden,
2) wasted capital, and
3) a labor vampire if the organization tries to adapt itself to it.
Careful examination and discovery of how well an application functions and enhances productivity is critical to selection. “So easy, even a caveman can use it” should be the ground rules for tool selection.
Creating a Wolf Trap performance
Selecting software is a balancing act between cost, functionality, compatibility, complexity and requirements. Until you know the process you are trying to address, don’t rush to make a selection. It could very well end up being a square wheel.
Comments