My opinion was the business department should be able to publish their processes and do all their evaluation stuff in ARCM themselves.
#Software ag software
I had this decentralization mission where I had some friendly fights with the consultants of Software AG. However, what is technically possible is implemented to get good results. That is the human interaction that you need. If it's correct on the technical side, but it does not make sense when you have to read it. For example, if it does not make sense, but it is formally correct. Therefore, everything is perfect on the technical side, and on the control side, no mistakes are published. It is only allowed to get the symbols which are permitted. If there is the smallest mistake in it, then you can't publish it at all. We only get emails if something went wrong or the semantic checks are integrated, which means you can't publish it. With ARIS, it is really well-implemented. Normally, it's always painful because it's coded badly. I like it because there have been so many bad experiences in the past with drawing or doing something in a browser. ARIS works perfectly on diagrams in the browser, so I was excited. If you ever tried to draw a picture in a browser app or with a cloud service, it is normally a painful death. Therefore, we have possibilities that we did not have before.
It has everything that we normally would want to have if we use an integrated process management system that works fine. They have a list of business applications that are used within the process documentation, where there is one list of organizational departments interacting within this process. The implementation of the completely decentralized process management, meaning that business departments can simply document their processes and flowcharts to improve their businesses, is now in one system. I only need to take the results and put them together for the board's report.
Now, we have a fully automatic-supported risk evaluation each quarter. We use the ARIS APG programming to get the approval and publication processes. After that, we use the risk evaluation and control execution using ARCM Risk and Compliance Manager, where they can do everything with the risk, e.g., how much is our risk? How much is the risk now? They evaluate that and do a controlled execution. There is a review step from the process expert to her/his boss, then it is approved and published. They can do that completely themselves on a technical level. In normal, day-to-day business, when a process is drawn, our expert team can review the processes, risks, and controls. This integrates risks and controls directly on a flow chart, making it easier for non-super process experts to get an idea of the steps, controls, and risk as well as how this all fits together to get a good overview at the starting point when working with these processes. At the bottom, we decided to use only a business process model notation (BPMN), which made it possible for us to integrate on this flow chart. These are in a hierarchy built up through the company and our business use cases since we have export and capital market services. We are using Connect and ARCM. ARCM is the ARIS governance, risk, and compliance module to do workflow-orientated stuff, e.g., how much is your risk.Īnother use case is value chain processes. We managed to get it a little bit separated, but it has good connection process management, internal control systems, and a risk system. It fits all together, so there are no completely loose ends, where there is one philosophy and one architecture behind it.
We tried to get the different solutions out of the one system to see them as different solutions with different responsible people with different roles behind them. This is all integrated on the technical side and the tools' side.
#Software ag how to
We had risk management and how to get a picture up of the actual risk evaluation. We had some kind of internal control system, which was one use case for us. You also need the hierarchy system in the process design to get an idea of which business area it is, which products we handle there, etc. This is to get some kind of a systematic approach to a wide area of the complete company, e.g., which services are delivered from whom and how it is organized. So, we try to get the complete process model in all the layers. There is a hierarchy model through the processes themselves to locate, classify, and build a whole tree off of the complete process design. In the end, there is a result event of the process. There is the start event, then there are the tasks and steps as well as risks on the steps and controls.
0 kommentar(er)
