In many engineering departments, innovative concepts and ideas emerge in response to specific business challenges. Engineers, for example, immerse themselves in the subject matter to address these challenges. They collect data from various sources, pour it into spreadsheets and obtain new insights or use the spreadsheet as a tool for future tasks. On the other hand, data analysts are more likely to have set up an analysis or experiment in a Databricks notebook or trained a Machine Learning model.
Often, these results or tools prove valuable not only for themselves, but also for other (administrative) departments, workplace workers or even customers. But how do you transform a conceptual technical idea into an operational tool useful by people who are no engineers or data analysts? More importantly, how do you ensure that these people actually start using this tool?
From idea to app
Technical departments are often good at coming up with innovative concepts and data structures. However, going from a proof of concept to an operationally useful tool requires another set of skills: technically building an application and thoroughly understanding the user’s work processes to make the tool integrate well. The last aspect should not be underestimated in an operational environment. We all know an example of a well-intentioned tool that is not used because the old way of working is more efficient.
Choice of technology and architecture
When developing an application, there are several factors that influence the choice of technology and architecture. Does the application need dynamic access to external data, does it need to store data, who are the users, do users need to authenticate, are there different types of users, are there security considerations, in which environment will the application be used (administration, production, outside workers), is interaction with other applications desired? These are just a few of the many considerations. It is important to consider all these factors and only then decide on a technology and architecture and not the other way around. Technology should serve the user and not the other way around. It seems logical, but this is often sinned against. Indeed, vendors and technicians like to use technology terms, while the quality of the code and the usability of the application will have much more impact on the final ROI. Nobody benefits from an application with low adoption.
Benefit for the user
To be usable in an operational environment, the tool must provide a benefit to the user or the organization. It is not enough to list the ‘functional requirements’ as they are too general to guarantee a user-friendly experience. Think of how you would describe a car in functional requirements, in many cases both a Porsche, a Smart or even a van will meet the functional requirements. Application creators must have the will, the interest and the gift to understand the user. So investment is required in understanding the processes and having a dialogue with the user. Together, they need to think about how the application works best to generate a productivity gain or quality gain. This is often an iterative process that requires some flexibility from the application’s creators. It is therefore important to take that need for flexibility into account when designing the architecture.
Data maintenance
Another important aspect of usability is to avoid double data maintenance. It is one of the most common complaints from employees that certain data has to be entered in different (non-communicating) applications which is not only counterproductive but also very demotivating. So make sure the application retrieves data when it is already available.
Key steps to success
Turning an innovative idea into an operational tool can be a challenge, but when done right, will not only generate a good ROI but will also motivate users. Whether you work with your internal IT department or an external partner, it requires:
- A well-developed proof of concept.
- Technological knowledge to build an application.
- Experience in taking ownership of business and work processes.
It starts with an idea and ends with a powerful engine that drives organizations.
