Skip to Content was having a ‘conversation’ with a colleague around my stockades versus castles analog and he doesn’t seem to like it much, I think because he felt that from a finance perspective at least, the idea of something impermanent was a cause for concern.

Sarbanes Oxley and IFRS as examples have been around long enough now that pretty much most organizations that are bound up by it don’t fret too much about having to set up the relevant controls unless they are converting from private to public companies; that said, the controls still need to be monitored and although you can have too many controls, you can’t have too many checks and monitors on whether your controls are working.

Accordingly, because of the maturity of the requirements of these controls, there is less concentration of effort on implementing new ones. For the most part what is being done is revision of the way the existing controls have been implemented. In the world of controls, establishing a control systematically either as a manual or an automated one requires a level of effort and commitment that initially may be difficult to stomach but with the passage of time becomes part of the normal cadence of business and is generally accepted and so becomes something that people perhaps criticize, but generally accept as being required. Paying lip service to a control though doesn’t ‘cut it’ when the control can be circumvented because of weak implementation – this is where the stockades analog falls down, if the control can be swept aside relatively easily or can be undermined or eroded by people working out how to dodge aspects of the control then the control fails.

An example of a defective control is the mandatory sign off on manual journal postings. In many conversations with finance leaders I ask the question about how manual journals get approved and I am told that a screen dump or a summary document is produced and then manually signed by a responsible and accountable person and the posting is done. That’s the theory at least. In most cases, the signature is done after the fact. There is an element of blind faith here on the part of the signatory, that operationally at least, the manual journal will have all the aspects that the sign off sheet indicated. From an audit testing perspective though, this control could fail. If the end-to-end process is not tightly integrated there is a risk that the signed piece of paper doesn’t reflect the action performed.

Most internal and external audit entities support the notion of electronic signatures. Some require them to be secure digital signatures but for the most part and action performed electronically that is hard to spoof or fake. Using an internal electronic form based approach to get the posting approved is all very well if the associated collateral  has tight SAP integration for example but if the process stops at the signature, requires a manual step and then a resumption of the form workflow process without a hook to the integration step then this is only slightly better than a paper sign-off.

how does this relate to concrete vs stone?

Well the idea here is that if you continue along the line of dialog that I previously posted on, around the idea of securing the defenses of your finance system; the question becomes one of what are your choices? You can use the document park and post capabilities within SAP to get those necessary approvals, but if you’re using the park function, this means that whoever is the ultimate sign-off signatory, needs to also be an active SAP ERP user. Does it make sense to have the VP of finance or the CFO work within SAP transactions or is this something that is done by proxy? Getting a senior member of the management team to sign off anything is pretty hard these days with their busy agendas and getting them to do anything in the ERP system is extremely unlikely. More likely, is that if audit forces them down the path of having to appear to sign off on something, that they do it through a proxy like an admin assistant or a designated other management team member who, *gasp* !shock! #horror# has access to their password. As they say in never-never-land “All the world is made of faith, and trust, and pixie dust.” There are those you can trust and then there’s the rest…

The idea with concrete is that you define a process with your own definition of flexible attributes. This is a definition that is bound by things like system ID’s organizational Hierarchies and approval limits etc but it is non prescriptive about the way that you design it or the way that you leverage it. Using a flexible workflow tool outside of SAP and hosted on SharePoint together with an infinitely flexible tool Microsoft Excel and then having tight SAP integration for the SAP record creation or maintenance is aligned with this thinking.  This ‘fluid’ approach, similar to the characteristics of concrete, hardens over time and when it is wrapped around a process as a control, again becomes something that can be as hard stone after a point in time but before that hardening point can be adjusted and tweaked to accommodate discoveries and revelations associated with establishing or re-establishing the process. The point here is agility and rapid application development. There is no requirement to be completely certain on the approach at commencement it is something that can be morphed as the process and design discovery matures. Setting something in stone like deciding that all journals need to be parked in SAP and when approved by a designate, posted,  commits you to a path of use that is difficult to adapt later without completely re-architecting your approach. Additionally, parked journals floating around in SAP

The challenge with most ERP related processes and especially controls is that they tend to be very digital, they are either on or they are off. You also can’t necessarily have as many or as few as you like. Often you have to make major efficiency compromises when you implement controls. We see this in something as simple as moving from standalone batch processing of mass actions in SAP with Winshuttle Transaction to moving to centralized script control and governance with Winshuttle Central on SharePoint; customers who have lived in the frontiersman world of build and run your own scripts independently, now become accountable to a centralized script repository and have to follow some rules. Working with ERP often requires understanding that the building blocks for control and governance are like large slabs of sculpted stone; if you want them to fit together neatly and inline with your business objectives (because you don’t like SAP standard) then you need to involve an qualified stone mason (ABAPer) to customize the shape – this takes more time than if you were to use concrete. Using stone masons is also more expensive. Additionally, if you want to have a really large control, it either needs to exist or be built from scratch. Extending the analog further, if you want big building blocks, you need to quarry big stones. Now you have all the logistics (transports) associated with getting that stone from the quarry to the building site.

If you ever visit the ruins of Pompeii or the pantheon you might be surprised like me, to find that the great Roman columns were made of brick and hydraulic setting cement (opus caementicium) and not stone. The Romans took the best ideas and building concepts from conquered nations such as the Greeks and these included the Doric, Ionic and Corinthian columns and used more efficient and less expensive building methods and by the middle of the first century, the material was used frequently as brick-faced concrete to great effect.

So in conclusion, my thoughts are that if you’re looking to implement or re-implement controls consider your options. From an audit perspective, the golden thread of traceability and proof needs to remain intact and have a level of integrity that reassures those undertaking scrutiny, it doesn’t require you building with stone, sometimes building with concrete will actually be faster, cheaper and more palatable – especially if you have to do rework.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply