Use Software packages for Commodity Solutions



But the Transformation team spends a lot of time creating Commodity Solutions, although they don't bring any competitive advantage.

The Baker would prefer the Transformers to take care of the Business Solutions, which will enable him to improve the key Processes of his enterprise.

There is a vast choice of off-the-shelf Software packages on the market for commodity Solutions. They are quick to implement and allow us to focus on the core business.

The Baker asks that any specific developments for commodity solutions be abandoned and replaced by Software packages.

  1. A software package industry has grown up around Commodity Solutions

    As Commodity Solution needs are similar between Enterprises with different activities, a software package industry has developed around these Solutions, and has done so all the more rapidly due to the huge size of the Market.
    Oracle, SAP, Microsoft, Google... have built and Distributed Commodity Solutions used by a growing number of Enterprises.

    These Software packages today have 2 forms of distribution: either in license form, which enables internal use in the Enterprise, or in SaaS or Cloud form (see the CEISAR Cloud white paper).
    In both cases, software development is handled by the supplier even if adaptations are often necessary.
    Today, we no longer therefore develop a human resources management Solution internally, we turn to a software package that includes not only the software but also the related human Procedures. The advantage, for Enterprises, is that
    • The Business managers can visualize, when choosing, a concrete Solution that is already available and offers part of the desired Processes. If the Business Units have suffered from past failures during a badly managed project, they can feel relieved and reassured to rely on a Solution that has already been deployed successfully in other Enterprises.
    • The Business managers' task of defining new Processes is simplified: they carry out more of a gap analysis, at the time of choosing, to check that no functionalities are missing, which is far less demanding.
    • Costs and deadlines should be reduced compared to an independent Solution as the Software package investment and development are shared between several Enterprises, including developments due to changes in regulations.
    • the Software package has been better trialled and tested, has better availability and richer functionalities than an internal Solution.

    On the other hand, the Software package can turn out to be heavy for smaller customers if the package is built as superset of needs for everyone and not as a modular set where we only select what is useful.

  2. The Software package can only be an answer to Business Solutions if it is built from Components.

    A Business Software package industry is developing today.
    However, it is more difficult: on the one hand, the market is limited to enterprises with the same Business, which might discourage investors. On the the other hand, the will to differentiate is stronger, which requires the software package to have easy modularity, therefore being more difficult to build.

    The Software package Solution can only be an answer to Business Solutions if it is built from reusable Components: the modularity must mix the capability to be able to stand out with the robustness of common architecture, but in that case, the level of requirements is higher for the Software vendor.
    As Businesses change ever quicker, it is extremely difficult for Business Software package suppliers to satisfy existing customers and, at the same time, go after prospects who are seeking, from the software package, the latest digital functionalities.

  3. How do we select a Software package?

    We have to take into consideration not only the available Functionalities, but also the overall costs and deadlines.

    1. Functionalities and ease of use

      An already-available Solution is always more attractive than a Solution that must be Built.
      A "Commodity Solution" will, of course, evolve with changes to the organization and regulations, but it will always develop within a known perimeter.

      Therefore, the first criteria of choice are naturally the availability of the required functionalities for the Enterprise and ease of use, that is to say everything the end user sees.

      The other criteria are the installation time, the cost (particularly for future additions), the longevity of the supplier, the ability for it to be integrated into the enterprise Architecture  (duplication of data, specific user interface, specialization of the Transformers), the possibility for differentiation, and the speed of development.
      It must be the full cost: the purchase of the Software package (license or use rights) is only a negligible part of the total cost. We have to add:
      • Cost of personalizing the software package during its installation and its life in the enterprise
      • Cost of interfacing it with other Solutions
      • Cost of migrating data to the software package
      • Cost of upgrades
      • Cost of optimization and tuning
      • Cost of Deployment: training, hardware installation
      • Cost of use for the end user: the cost is higher if the usability Model of the Software package is specific
      • Cost of operating the solution
    2. Do not forget the software package's capability to evolve

      But one essential criterion is often neglected at the time of choosing: the evolution capability of the Software package.
      Yet, Solutions have to evolve:

      • Regulation changes
      • Technology changes
      • We are able to automate an increasing amount of functionalities and the Software package is gradually enriched
      • We connect an increasing number of Mobiles to the Solution
      • We share some of the functionalities with partners and customers
      • The Software package has to be interfaced with other Solutions.

      If the Software package has a real capability to evolve, it will be easy for the vendor to add potentially missing Functions or to optimize its performances or its reliability, in other words to gradually compensate for any weaknesses in the Software package. Otherwise, the installed software package will quickly age and will have to be replaced rapidly, which is not always really understood by the users.

      To judge the capability of the software package to evolve, we must not hesitate to understand its architecture, to question existing Customers of the software package on how easy it is to upgrade or personalize the Software package.

      For more information, see the software packages white paper.

Licence Creative Commons
The story of George the Baker is made available under the terms of the
Creative Commons Attribution - NoDerivatives 4.0 International license.
Table of Contents

Comments

comments powered by Disqus