Are integration and TCO really two sides of the same coin?

    One of the most classic views of the systems supporting the finance area of ​​a company is like the one you see below, developed on three levels.

    Software CPM: master or slave?Often, analyzing the individual layers we find a heterogeneity of vendors linked to decision-making policies that are not always consistent with the minimization of the Total Cost of Ownership (TCO) and with the maximization of benefits for the users of the various applications. The same IT or business philosophies that may vary over the years, even due to changes in top management, do not help to make these choices with a spirit of efficiency. Without considering the plurality of systems that groups of companies have to manage following acquisitions that have taken place over time.

    Integration or Best of Breed?

    Wanting to simplify it, we could schematize these philosophies of choice with two opposite extremes on paper:

    • Best of breed
    • Integration

    In the first case, there is a tendency to choose the solution that, from time to time, on the market best suits the needs of the business, while in the second, there is a change of vision in making the choice of software and leaning forward to cover more processes possible with what the vendor offers. I don’t think there is a better philosophy. I believe that each situation has peculiarities to be analyzed in the specific business context.

    Over the years I have seen shipwrecked integration projects also as a result of continuous changes in the consultancy companies that were in charge of project delivery and “vertical” projects causing maintenance costs so high that it was necessary to evaluate a review of the entire application map to solve the problem. I am convinced that choices of this type cannot be made exclusively by following application dynamics (product road map, technological integration, …) because the analysis of the characteristics of the processes that these applications must support must remain a priority.

    A software to support the process: not vice versa

    It is not possible to make application choices by totally neglecting the soul of the process that these applications must support. Because it is the process that needs to be supported by the software, not the other way around. 

    It is hardly ever correct to overturn business processes to adapt them to what the software is able to offer. Over the years, business processes certainly deserve a review both in terms of governance and flow of activities. This does not mean that they can be distorted simply because the choice of a company is to take that software that has little or nothing to offer on that specific process. This does not move in the direction of minimizing TCO and maximizing user benefits.

    More than once I have seen companies make choices under the umbrella of integration and then customize large areas of finance processes just because the specific vendor had little to offer in those contexts but at least the relationship with one vendor was maintained by pursuing the “false myth of integration “. Because in these cases, in addition to the costs related to the various customizations (first delivery but, above all, maintenance), those related to the likely inexperience of the vendor must also be borne (because if it has little to offer on a specific process, it is likely that the reflection is also found on the experience that this can bring on the field).

    Not to mention the effects on the business processes that this software has to support and on the relative satisfaction of the users. It is clear that in a context that is not easy to read, even the choice to operate by default with the best of breed can only lead to an excessive fragmentation of the applications, losing the benefit of integration which remains, however, one of the elements of maximum attention in the optics of TCO minimization.

    Of course, the choice of a single vendor in all ERP, CPM and BI areas cannot and should not be considered an integration factor. Simply because it is not true. The vendors, while remaining under the usual name, offer different software to cover the different areas that are almost never integrated and that do not even have compatible product road maps. This is all the more true when greater is the search for a vertical integration (cross between the 3 layers listed above) rather than a horizontal one (within the same layer).

    Horizontal and vertical integration

    My personal twenty years of experience in the field of applications to support the finance world allows me to recognize when the lever of unification under a single vendor is more a commercial key than actually seeking lasting benefits for the entire corporate ecosystem. As already written before I believe, at the same time, it is impossible to identify a vision that is correct in all contexts. However, I am convinced that there is no single vendor on the market capable of covering all the layers mentioned above, with a view to maximizing the overall benefits. And, if integration is to be sought (and must be done), it must be horizontal, not vertical, as there are software on the market capable of covering the layers very well taken individually but not all together.

    Also because while choosing the same vendor to cover the 3 layers, the products supplied are different and to date there is no integration between them in the full sense of the term. I think the choice of a company capable of directing the choices is of fundamental importance in revisiting the application landscape. Here too, however, maximum attention should be paid to the reference partners because often one falls into the net of the gamekeeper who becomes a poacher by proposing what is more convenient for his own pockets rather than for those of the company he should recommend. But this is another story…