Chances are high you’ve likely made a significant investment in your ERP and back office systems. Yet changing business environments require you to either build additional infrastructure or buy a 3rd party product. It’s necessary to in order to expand integration capacity or to update the front end look and feel of the application.
Making a choice between building or buying a solution is nothing unusual in the business world. After-all there are simple factors, such as logistics, quality, and sustainability, which help to determine whether a company should in-source or outsource a finished product.
From an IT perspective the factors are largely similar. Development resources are often expensive and usually run a relatively lean in terms of technical resource and rely more on functionally competent resources. If we take the simple requirement of enabling users to load data en masse (with little or no IT support) we can pretty quickly determine that this will result in better data-entry, business user productivity and an overall reduction in data management entry and maintenance costs.
Business who have the capacity to build their own loading utilities, with minimal effort and without the need to program, are a step ahead of others. This freedom allows them to load data from environments that are ubiquitous and relatively common, like Microsoft Excel. This game changing feature provides businesses a huge advantage and extends the life of your core systems with limited risk.
Need a software interface – do you build it or buy something?
ERP’s typically contain hundreds of data entry methods and interface opportunities. However, business users are generally only exposed to those that are required to achieve their objectives. As a consequence these same users become intimately familiar with the quirks and nuances of these entry screens or existing tools.
Implementing a batch entry method that stages the data in advance is straightforward but applying an interface to the staged data typically requires a program. Once again, businesses have to choose whether to build or buy that program.
Typically custom developments require a high level of functional and technical expertise for design, implementation and on-going support. This highly personalized approach can in turn represent a substantial hidden cost to the business for custom integration. Consider for example Amazon.com, whose business is differentiated from their competitors, by virtue of their systems.
Amazon obviously chose to build their systems themselves. As their CTO, Werner Vogels, points out: “Build your own infrastructure for performance, reliability, and cost control reasons. By building it yourself you never have to say you went down because it was company X’s fault. Your software may not be more reliable than others, but you can fix, debug, and deployment much quicker than when working with a 3rd party.”
If the Amazon model is not optimized for your business -than why build technology super highways to interface with your back end systems if someone has already developed something that is ready to use?
Diversity of Landscape and control of resources
To evaluate whether you should make or buy your own interface technology consider the software development lifecycle.
Any company with a large ERP investment, such as SAP, will likely have dozens of equally large Microsoft .NET based systems (mostly internally for engineering systems), as well as Java platforms (mostly for external web applications). As such, they will often have large development shops for ABAP, C#, and Java. Instituting any system alterations may span multiple platforms and involve many impacted participants and landscape components.
The larger an organization becomes the more likely they are to outsource the sustainment of some areas in order to keep head-count and overhead costs as low as possible. Customized solutions can become incredibly expensive very quickly when the hand-off to an AMS (Application Management Service) carries the added burden of project managers analysts and programmers.
Changing Requirements & Time to Delivery
The first factor to consider here is the diversity of the landscape and the level of direct control that you might have over development resources. There’s also the dilemma of when to initiate changes. Often by the time many are implemented, you may have already started your next round of changes. The ability to move with agility to the changing demands of your business is compounding by a lack of control over the development resources.
If your approach is to tackle problems as they arise as opposed to one that involves some degree of planning then you rapidly run out of budget and resources when you have no proper means of planning your pipeline of change.
Large ERP projects are notorious for having execution cycles with an average of 9 months. The more contemporary approach of implementing software solutions is to use Agile development techniques in gathering requirements, building prototypes and testing and unfortunately this approach doesn’t necessarily lend itself well to the classic ERP Waterfall methodology.
The rigor of Waterfall dictates that you have to clear a number of gates before you move to subsequent stages in the software development lifecycle. Proper preparation, design discussion and scenario consideration will ultimately save time and rework will be avoided. Ensuring your requirements are nailed down early and as completely as possible is key. Agile conversely, would argue that you can start with generalized requirements and recursively build and evaluate until you believe you have a solution that will largely meet the requirement. This approach facilitates spending more time driving to something being delivered in a timely, without a potentially stale set of requirements. For the business, this latter approach is much more appealing, but comes with a significant participation burden. Those for whom the solution is being developed have to make a bigger time investment in making sure the solution addresses their needs. Either of these approaches could have the same cost structure in terms of budget but certainly the Agile approach may prove to be more of a challenge if your IT organization doesn’t support an agile approach.
Software that Supports Agile Rapid Application Development
Several software companies, including Winshuttle, produces off-the-shelf-software that support the agile approach to performing rapid application development. Such software supports this process by providing a platform where authors, rather than developers, can use to build solutions.
This approach relies heavily on business users’ intimate understanding of how they use their transactions and build to manipulate their business data. Using menu driven applications the software deftly exposes transaction screen logic, or API’s, in an array of UI formats, including Microsoft Excel to Microsoft InfoPath Web forms. The main benefit is the ability for the end-to-end solution building, which doesn’t require an army of resources. The author can function as the analyst, the builder and the publisher as well as the consumer of the solution.
This approach really lends itself to the iterative design, prototype, tweak and retest approach that is characteristic of agile software development but it also empowers the more advanced business user to build complex automation and interfaces without the need to have any in depth understanding of much more than the logical objects that they use on a regular basis. More importantly, the design of UI is all reduced to a rudimentary but flexible Microsoft Excel COM add-in.
UI design often consumes the largest part of effort in application development but with this approach of componentized creation of solutions the UI is consistent for everything from Journal Entry to Material Master Creation. Microsoft Excel is the most commonly used data staging area and users can customize the labels, the look and feel, and pre-validation of their data using the tremendous power of Excel with little more skill requirements than anyone familiar with the rest of the Microsoft application family.
Customization, which is often a stumbling block with COTS software overcome by the flexibility of being able to expose the APIs the way you, as an author, want to expose them. You get to determine how the underlying interface will logically behave and you get to determine how the front end experience should largely look and feel. Ironically, even if you have invested in customizing your back end ERP system like SAP, even that is accommodated, since your API recording of the transaction will incorporate those customizations.
Re-facing legacy applications isn’t really anything particularly new. However, the newest generation of solutions for application development doesn’t simply emulate the behavior of the existing back end system. They in fact augment the validation, and capability, by allowing you to insert additional user experiences into the end-to-end data entry, inquiry and update process without necessarily changing the underlying core architecture of the backend system. This approach is safer in that it is more secure, faster and almost always cheaper than engaging in custom application development to renew aging platforms.
Questions or comments about this article?
Tweet @uploadsap to continue the conversation!