![\"Chris](\"https:\/\/www.quantiv.com\/wp-content\/uploads\/2021\/03\/Chris.png\")
Chris Conway
\nChief Architect, Quantiv<\/p>\n<\/div>
When I see how organisations approach their IT system implementations, I often think, \u201cThere has to be a better way.\u201d<\/p>\n
In many situations, while it\u2019s clear IT could make a considerable difference to their operations, the prospect of going through the whole process can seem daunting. First there are the perils of choosing the supplier\/system, and then there\u2019s the potential pitfalls of deployment.<\/p>\n
This is especially true when enterprise resource planning<\/a> (ERP) systems are involved. While such applications are usually highly functional, this breadth of capability can often be the source of problems, for example:<\/p>\n Using smaller, more targeted, or customised, applications for dedicated functionality can be just as frustrating. These may allow for better matches to specific requirements, but the different applications can often fail to connect easily with each other.<\/p>\n And in some cases it can almost feel as if applications are actively refusing to cooperate. They might seem to be building walls around their own functionality, and yet trying to take control of functions in other areas (a sort of operational \u2018land-grab\u2019).<\/p>\n It\u2019s these two extremes that suggest the need for a better way \u2013 an \u2018antidote\u2019.<\/p>\n As is often the case when things converge around extremes, the antidote lies in a combination of the best of the two extremes.<\/p>\n So, the answer isn\u2019t a complete rejection of the original ideas, but more a reimagining:<\/p>\n But with this approach, the organisation must understand its processes, and in particular how the individual activities within those processes interact.<\/p>\n In turn, the IT solution architecture supporting the approach needs a mechanism to allow applications used within those processes to communicate information about those activities. So, \u2018producer\u2019 applications must control how information is exposed, while \u2018consumer\u2019 applications control how information is used.<\/p>\n And the individual applications within the solution must not only conform to the solution architecture but actively embrace it.<\/p>\n An appropriate analysis method will help an organisation to understand its processes. But the method is not simply about describing organisational operations in infinite detail.<\/p>\n Instead, what\u2019s required is something that highlights (ideally only) those aspects of an organisation\u2019s operations<\/a> that will be most useful in defining the points at which different applications should interact. And these points often also correspond to the points where organisational performance is monitored.<\/p>\n In effect, this means analysis of this sort is useful both to support IT integration and in monitoring operations.<\/p>\n (As an aside, you could argue this lack of understanding leads to problems with traditional ERP projects and buying the wrong dedicated applications.)<\/p>\n A cohesive integration platform will help because of its well-defined boundaries and the fact it only operates within those boundaries. It doesn\u2019t need to encourage implementation within the platform of functionality that should be implemented elsewhere (usually in the producer or consumer system).<\/p>\n It\u2019s worth noting the terminology here. \u2018Producer\u2019 indicates it\u2019s the responsibility of those applications to decide what data should be exposed, while \u2018consumer\u2019 suggests it\u2019s the responsibility of those applications to decide how data should be used. Neither should assume the other’s responsibilities. And the integration application should only be responsible for allowing the data to be exchanged; it shouldn\u2019t be responsible for interpreting the data.<\/p>\n When using this approach, information<\/a> can be shared among applications, while significantly limiting\u00a0functional dependencies. So, publishers don\u2019t need to demand how consumers will use their information, and consumers place no obligations on publishers of information.\u00a0And that means producers and consumers have minimal dependency on each other, while information is exposed as widely as possible.<\/p>\n By defining the scope and responsibilities of the applications and by describing the way in which they should interact, benchmarks can be established to help select possible applications.<\/p>\n Quantiv\u2019s NumberWorks<\/a> method is specifically designed to highlight these aspects of an organisation\u2019s operations. But what\u2019s important isn\u2019t the specific method, but rather the information gathered by it.<\/p>\n Likewise, our NumberCloud service is designed to support a cohesive model of information exchange. But again, what\u2019s important are the principles not the specific product.<\/p>\n And taken together, perhaps they constitute a better way to approach solution design \u2013 the antidote to ERP struggles.<\/p>\n Talk<\/a> to our team on 0161 927 4000 or\u00a0email:\u00a0info@quantiv.com<\/a><\/p>\n<\/div><\/div><\/div><\/div><\/div><\/p>\n","protected":false},"excerpt":{"rendered":" When I see how organisations approach their IT system implementations, I often think, \u201cThere has to be a better way.”<\/p>\n","protected":false},"author":1,"featured_media":1732,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":""},"categories":[1],"tags":[],"yoast_head":"\n\n
What about customised applications?<\/h3>\n
Reimagining IT<\/h3>\n
\n
The right analysis<\/h3>\n
Cohesive integration<\/h3>\n
NumberWorks and NumberCloud<\/h3>\n