System theory has two design approaches when it comes to implementing a system. As Alex Lichtenberger explains, these two are top-down or decomposition, and bottom-up or synthesis. Each of these two approaches has their champions and their detractors, but what Lichtenberger has his eye on is how to utilize both systems to provide the best solution.
He begins by explaining both systems in brief. Essentially, top-down is the older approach of the two and seems to make the most sense from the surface. Top-down starts with recognizing what your organization needs, designing the IT service support around the business process, defining the processes to support that service, define roles, and find the tools to do the work itself. This seems very logical indeed, as it follows the why/what/how/who/with what process that IT thrives on. But Lichtenberger knows it isn't quite that cut and dry:
In theory there is nothing against such an approach, but if you have followed it ever in practice, you know how costly and time consuming this can get. This becomes especially a problem because many of the IT processes that are in focus of an ITSM project get more and more industrialized (typically this would be: Incident-, Problem- and Change-Management etc.). Let's put it this way: Is there any real reason why an Incident Management process should look in one company completely different than in other ones? Not really. The only reason I could think of is to get as a company a competitive advantage out of it (you differentiate yourself in the market). As this is most probably not the case, you therefore just could buy a tool with predefined templates and build some KPI's and resolver groups around it?
The bottom-up approach is quite a bit different. Gaining traction recently, the bottom-up approach re-uses out-of-the-box solutions through IT Service Management vendors. Framing itself on cost efficiency and quick implementation, it also has its drawbacks. For instance, this process focuses on the tool and not the problem to be solved. Likewise it doesn't put emphasis on governance or process, which can ultimately hamstring an organization no matter how good the tool is they went with.
Here is where Lichtenberger presents his argument: combine the two. Look at the environment your organization is currently in and determine which of the two solutions would make sense to start with. Then, define how much “service management” you want and how much uniqueness (more appropriately, customization) you need to thrive. Starting with a top-down approach and then molding into a bottom-up approach once your processes are in place is a smart way to make sure you don't lose any of the value brought by rigid structure while still gaining a cost-efficient tool to utilize.