The aim of this blog is to share my technical interest with constructive critics and to broaden my personal horizons in the discussion I would like to have.
Companies today still rely heavily on IT solutions that can support a task very well or take it over automatically. Often, software is selected according to the best-in-class principle, which then has to interact with other software via interfaces (or an Excel export) or provide data for the further process. Therefore, on the one hand, there are many users who are very well versed in a software and have thus built up a lighthouse knowledge for their area. On the other hand, from an IT perspective, there are many interfaces to maintain and no real single point of truth due to many Excel sheets in various versions. To counter this dilemma, agile process models and user-centred personas have been used in software development for quite some time.
In addition to a well-designed user interface, user-centric programming also includes the aspect that image changes should have the same “look and feel”. Now, a persona is usually limited to one role for which the software becomes intuitively operable. Another programmer will similarly depict another persona, after all, one talks to one’s programming colleagues. What falls by the wayside, however, is the chaining of personas into a process and the possibility that, for whatever reason, employees complement each other, possibly even having to take on a different or additional role at times. Faced with the above-mentioned challenge of isolated applications, one either builds a replacement lighthouse or uses the possibilities of a uniform technology platform to reduce the isolated applications as much as possible (some special applications will not be able to be replaced).
Therefore, we now look at a software company that has the task of mapping a whole area with all its processes or even a whole company with all its processes with a uniform software solution. In the case of so-called ERP systems, the programmer can fall back on a code library or corresponding style sheets, so that the “look and feel” remains the same at the core. ERP systems actually come with all the processes and activities that a company needs to manage its tasks. Most of the time, however, these are so general and broken down into such small units that the user has to execute many of these standard functions in order to achieve the necessary result. On the one hand, this harbours sources of error, and on the other hand, it requires well-trained users, as in the case of an isolated solution. Individual characteristics of the software are not even taken into account due to the cross-sector approach of such a technology platform.
Now one finds oneself in the area of conflict between the standard that an ERP system brings with it and the individual characteristics of the customer. A software architect can integrate standard functions into the customer’s individual processes in such a way that a software-supported, intuitive continuity is achieved for each end-to-end process. The wheel is not completely reinvented for a customer. If a suitable persona is used for the individual activities, nothing stands in the way of a successful transformation to an integrated solution on a technology platform.
