Not every app is an enterprise app

The primary objective of investing in enterprise apps is ultimately to derive useful and actionable outputs for your company. App developers know this, and seduce buyers with fancy graphs, KPI dashboards and reports. But simply showing compelling output for a small demo environment is the easy part. Making sure the input is solid and up to date once it’s live in a multinational enterprise with hundreds of users is a whole different ballgame! Unfortunately, because this is the “boring” part, it is often neglected during the Sales stages. To ensure that you have all the details you need to make an informed decision when buying enterprise software, our VP of Product, Joachim Lasoen, outlines all the special requirements you should consider.

Here are some important questions that people should consider carefully when selecting the right software for their organization’s needs:

• Is it easy and fast for the users to keep the input up to date (and especially if working on this with multiple people)?
• Do users engage with working towards the same goal?
• Does the system work fast with masses of data?
• Do you have control over who changes what?
• Is the data secure?
• How do you to convince all employees to start using the system?

We have seen that many applications excel at the output part, but have insufficient support for the end-to-end business processes, including data capture and processing – a situation that is simply not sustainable. As a buyer, before you select the software app, invest sufficient time in a proof-of-concept that also uses large data volumes, focuses on how the input is managed, and offers the possibilities of real interfaces. With Binocs we’ve pivoted three times: First, we’ve built an Excel prototype. Correction! Not pure Excel, but an Excel front-end with a database that was used by about 200 users. Then we started with the Web app, which we have almost completely rewritten to solve performance issues with large data volumes. During these different phases we learned that enterprise software is about more than fancy output. I clustered the special requirements for enterprise apps in seven categories, and for each category I’ll give an example of how the enterprise architecture aspect influenced our own product and services (Binocs — capacity and resource planning).

Apps work well with small sets of data. User interfaces are responsive, and a dropdown box with 10 options is still workable; but with high volumes the performance and the data accessibility are at risk. Binocs example:

• We make extensive use of context-sensitive searches. As in Google Search, you start typing and the system intelligently suggests the possible options. In Binocs we have invested tons of hours to make this feature work at light speed with datasets containing thousands of items.
• We also implemented tagging and filtering features, which allow users to focus only on the important data for a certain transaction.

Standardization is a way of supporting organizations in executing their business processes in a standardized, “good practice” and lean way. Large enterprises are often struggling with this, and they see business applications as platforms to enforce standardization. Binocs example:

• In Binocs we provide the possibility of standardizing workload and lead times of activities performed by teams. We also allow teams to create work templates in a collaborative way.

Business process performance should be measured end-to-end. In large enterprises this involves different departments and roles. Special requirements for enterprise app need to provide visibility and stimulate interactions. Binocs example:

• Evaluating resource capacity issues and scenarios to solve these issues can be set up in a collaborative way.
• Binocs supports the process to share resources across teams.

Large enterprises roll out applications across different departments and geographies. This requires the engagement of many users. Often, we discover that additional activities are required to bring the organization to the right maturity level. Unlike in small companies that operate in a “Let’s just do it” mode, implementation is more than just putting the app live. The program management and change management components are as important as the technical aspects. Binocs example:

• In parallel with the technical app delivery, we deliver roll-out playbooks, change methodology, project management, and training and coaching.

More so than small companies, large companies are a target for hackers. They run company-wide initiatives to comply with data privacy and anti-bribery legislation. IT applications and cloud applications are subject to extensive assessments and audits. Binocs example:

• Large companies demand to run periodic cloud app penetration tests performed by an external independent company.
• Taking into account the special requirements for enterprise app of our large customers, we have set up a quality and security management system. It is auditable, and contains organizational roles, procedures and instructions that reduce the risk of security issues with the cloud production platform and the data stored on it.

Large companies that implement your cloud app on a large organizational scale expect a formal collaboration to enrich and evolve the product features and the product-related services (such as training, support, etc.). They also expect that you organize sessions, round tables, or user meetings to allow them to exchange ideas with their industry peers. Binocs example:

• One of our largest customers recently asked us to play an active role in a cross-departmental resource capacity management governance board. This role included PMO on active Binocs projects, quality assurance on the good practices, training of roll-out squad teams, and the like.

Global enterprises expect that the application you deliver fits in with their IT application architecture. As their experience with cloud apps is limited, they expect you to help with embedding the technical governance in their existing organization. As the data is big, they aim for interfaces between your app and the existing IT architecture. Double input is out of the question. Master data must be aligned between systems. These things barely come into play in small implementations. Binocs example:

• All our current implementations interface with LIMS, ERP, PLM, dossier management, SharePoint tables and other sources of data. These interfaces use a documented, standard and secure Web interface (API, application-programming interface).