Everyone dreams of business solutions that can be deployed from one day to the next and immediately adopted by users because they perfectly meet their needs. The reality is often very different: customization requests and integration requirements delay projects and often run counter to the anticipated benefits. An inevitability?

“Fully configurable” is a very positive-sounding characteristic in the description of a business software product: does it not promise a software product that is perfectly tailored to the needs of the company considering its purchase? In reality, these two words conceal several traps that can considerably delay the commissioning of a new tool, reduce its contribution and scope, or even trap you in inextricable upgradability problems.

Here are three questions you should ask yourself, and the publishers you are consulting, to avoid these pitfalls and derive the maximum benefit from the business software with which you are equipping your company.

Configurable yes, but by whom?

From the mid-1980s onward, the appearance of software packages – especially integrated management or ERP software – was a revolution for companies. Indeed, until then, the only way they could computerize was to develop, or commission the development, of bespoke software, a long and expensive process that only the biggest companies could afford. Software packages conferred the ability to equip oneself with cheaper software using standard software products that only required configuration. “Only required” was a euphemism: true, it was no longer necessary to write thousands of lines of code to have an operational tool, but the configuration in question still remained a task for specialists, namely in-house or external IT specialists responsible for tailoring the “standard” tool to the company’s specific requirements. The more seasoned among us all remember at least one of these interminable ERP or CRM implementation projects, the configuration of which ultimately entailed hundreds of man hours and millions of euros (or francs, back in the day).

Things have moved on! Since then, the software offering has become:

• diversified and verticalized to address the operational requirements of the company’s various business areas/functions (HR, sales, logistics, marketing, accounting and financial management, deliveries, planning…);
• commoditized, thanks in particular to deployment in SaaS (Software-as-a-Service) mode, affording the prospect of standard, ready-to-use tools after purchasing the subscription.

Notwithstanding these developments, implementing new business software is never as simple as is claimed, not only for change management reasons, but also from a technical perspective. Even if configuration has replaced specific developments, you still need to know what skills are required to carry it out: do you need to be a specialist in the software in question? Do you need to be an expert in the business area concerned, and its processes? Will you need external consultants? Can business management configure the features it wishes to use on its own? Is it really within the grasp of a non-technician, or is IT Department support required?

>> The answers to these questions directly influence the project’s cost and duration and, secondarily, the company’s ability to develop the solution when new requirements emerge.

Customizable yes, but to what extent?

Generally speaking, what drives the acquisition of new business software is the desire to modernize existing processes, be they already computerized or not, and to become more efficient in performing everyday tasks. Given the scope for configuration current software products confer many companies cannot resist the temptation of pushing customization very far to have a tool that exactly meets their needs. They embark on wholesale reconfigurations, additional developments, new features, user interface changes and many other time-consuming transformations which take them ever further away from the standard solution.

Of course, each company has its own specific cultural and organizational characteristics, and some customization measures are required irrespective of the software, if only because it needs to be integrated with the existing environment and interfaced with other software. This may be more or less complex, but it is indispensable if you want the new tool to achieve its intended purpose. On the other hand, every project manager will tell you that:

• many customization requests from end-users or management aim, more or less consciously, to replicate what previously existed, including that which was suboptimal!
• The desire from the outset to address every scenario and situation that users might encounter frequently delays the commissioning of a new tool whereas the standard version addresses cases/situations representing between 80% and 90% of what they do.

This is not without risk, the first risk being to lose sight of the primary reason for which this solution was initially selected: modernizing/rationalizing processes and overhauling in-house working practices by tapping into the good practices that the publisher has been able to incorporate in his software by harnessing his knowledge of the business sector or activity, acquired from hundreds if not thousands of other client companies.

The second risk is to have modified the software to such an extent, to have made it such a specific tool, that it becomes very difficult to benefit from the regular updates offered by the publisher – short of repeating the process of ultra-customization for each new version, with all that implies in terms of costs and timescales. In the absence of undertaking this effort, the company deprives itself of the feature enhancements and improvements provided by successive new versions. It finds itself with a stagnant and counter-productive tool, because it no longer meets market standards, nor sector/business good practice, nor consequently the users’ expectations.

>> Before purchasing the business solution you are interested in, ask yourself to what extent the standard features meet your organization’s and users’ needs. Confine customization to the bare minimum and above all, : by involving users, by familiarizing them with what their future working tool will do for them, you will avoid deadlock, push-back and superfluous customization requests.

Simple to use yes, but at what price?

In terms of the interface and user experience, consumer web applications have imposed codes and standards that professionals now expect to find in their business tools, especially in mobile applications. In numerous field activities, the end-user is not intended to become an expert in the software he is using. He just wants simple tools that meet his day-to-day operational needs without requiring hours or days of familiarization. The UX designers’ role is precisely to create intuitive applications and interfaces which shield the end-user from the underlying technical complexity, while  of the features available to him.

Beware however of 100% “push-button” applications, the alluring simplicity of which may be accompanied by feature poverty, lack of clarity, an absence of openness and, ultimately, low real-world usefulness. Tantamount to money down the drain…

>> Make sure that the mobile business applications with which you are intending to equip your delivery personnel, your technicians or your sales force are not “black boxes”, that cannot be made to communicate with other of your organization’s vital tools, especially your .

>> Both with and , your co-workers can be confident of encountering the terminology, tasks and processes specific to their job. This saves you time on configuration and you spend less on customization and integration.

>> If you absolutely insist on pushing things further and, despite everything we have just explained, building an ultra-customized environment based on our solutions, there is nothing preventing you from doing so: they are open and, subject to certain skills, fully configurable!