Workflow application for pharmaceutical operations
A custom web application being developed for a global pharmaceutical company's European operations, intended to replace spreadsheets and email chains with a defined approval workflow.
- Client
- Global pharmaceutical company, Europe
- Services
- Process improvement, UX and UI, software development
- Status
- In delivery
Context
The wider situation.
Many operational processes in large organisations begin in spreadsheets and email because these tools are familiar and quick to set up. As more people and steps become involved, the same tools make the process harder to manage. Status is held in individual inboxes, approvals are recorded in messages that are difficult to find later, and nobody has a reliable view of where each item stands or what is waiting for action.
In a regulated environment this matters beyond efficiency. Organisations need to show who approved what and when, and records spread across inboxes and files are hard to audit. Replacing them with a dedicated application brings its own obligations. New software must satisfy the organisation's security, accessibility and supplier requirements, and those requirements are much easier to meet when they are defined at the start than when they are checked at the end.
The challenge
What needed to change.
A core business process ran through spreadsheets, email and manual follow-up. Status was hard to see, approvals were slow to track and records were spread across inboxes.
Any replacement had to meet the client's security, accessibility and supplier requirements in a regulated environment.
What we did
Approach and work to date.
Mapped the current process with the people who run it and designed the target workflow
Designed the user journeys and interface with the client's teams
Defined security and accessibility targets, including OWASP ASVS Level 2 and WCAG 2.2 AA
Delivery in short iterations with vetted engineering partners, in a secure cloud environment aligned to the client's standards
The engagement is being run as an iterative delivery. It began with mapping the current process with the people who run it and designing the target workflow. User journeys and the interface were designed with the client's teams, and security and accessibility targets, including OWASP ASVS Level 2 and WCAG 2.2 AA, were defined ahead of release. Development is taking place in short iterations with vetted engineering partners, in a secure cloud environment aligned to the client's standards. The project remains in delivery.
Delivery perspective
The project combines process design, user experience and iterative development, with security and accessibility requirements defined before release.
Planning similar work
What similar organisations should consider.
Map the process with its users
The people who run a process each day know where it slows down and which workarounds have grown up around it. Mapping the current process with them, before designing the target workflow, avoids automating steps that no longer serve a purpose. It also builds the understanding and support that a new system needs when it is introduced.
Set security and accessibility targets early
Named standards give designers, engineers and reviewers a shared definition of what acceptable looks like. Agreeing targets such as an application security verification level and an accessibility conformance level before building begins allows them to shape design decisions. Leaving them until the end usually means rework, delay or compromises that are harder to justify.
Design journeys with the people involved
An approval workflow only works if people use it in place of the old routes. Designing user journeys and the interface together with the teams who will use them helps the application fit the way work is actually done. It also surfaces practical questions about roles, permissions and exceptions while they are still simple to resolve.
Deliver in short iterations
Short iterations give users something they can see and comment on at regular intervals, rather than one large release at the end. Feedback arrives while changes are still inexpensive to make. Working in this way also makes it easier to check progress against the security and accessibility targets as the application develops, instead of relying on a single final test.
Discuss a similar project.
Tell us about your project.