The Project
Partial automatization of Word documents makes our client’s employees happy.
The Problem
The Roche Diagnostics IT Solutions GmbH places great importance on the safety of its laboratory management software Swisslab LIS. The company applies the same high standards it uses for its medicine development - voluntarily. This means a lot of documentation for software development. As software developers, this is something we love to automatize.
A significant challenge here was the generic quality of the documents. They were intended for use by the whole Roche Group and changed and still are being changed quite frequently.
A partial automatisation would already pose a relief to the users.
The Goal
Our goal was to identify the necessary information and its sources, process the information and render the document.
As the Swisslab unit emphasizes agile development, we decided to work iteratively: We started out with a single document, a showcase example. We limited our scope to the low hanging fruits. In subsequent iterations we went/are going for more documents and more complex automatization.
Hence, we tried to employ generic solutions to document-specific tasks where it makes sense.
We chose to implement this as separate service with a web front end. The client asked for a solution in the Microsoft ecosystem.
The Solution
First, we chose which document to automatize: We interviewed the relevant experts and compared the costs and benefits of implementations.
Second, we checked which of the necessary information is (digitally) accessible. We found that the desired information could be grouped as follows:
- A few parameters need to be set by the user to start the process.
- The majority of the desired information is comprised of references on data in Roche IS.
- Some information could be derived from the first two groups.
Third, the implementation: We chose a web application from the standard Microsoft components (current ASP.NET framework, OWIN pipeline, Linq, Razor Views). This is not a standard kreuzwerker solution, which in this case however, we appreciated for its smoothness.
We separated generic and document-specific components:
- Each document is generated by a controller containing the workflow logic.
- Information is processed in generic function classes where possible.
- Interfaces to other systems are encapsulated and open to new requirements.
Forth, the access to a variety of data sources was not trivial. In a multination enterprise like Roche, the API-access to databases/IS is (for security reasons) very limited. Or not desired by some system vendors (SAP). The former meant convincing the party responsible to grant a read-only access. The latter was to overcome with some practical creativity.
Fifth, while building the platform was easy, processing a Word document proved unexpectedly difficult: Microsoft does not offer a suitable tool. We alternated to two third-party libraries with limited success. Have a look at the relevant blog entry.
Our Contribution
We offered a one-stop project to our client: kreuzwerker analyzed the problem, developed a concept and implemented it to the client’s requirements.
Generally speaking, our knowledge with distributed systems and web applications gave us a strong advantage. It’s our daily business.
More specifically, our relation to the client for many years, our experience with Roche structures, conventions and habits was crucial to the solution. Without a certain sensitivity to needs and requirements of the people in charge of IS the project wouldn’t have come far.
The Upshot
It quickly became clear that we relieved some strain from the users: Everybody asked for some document automatization afterwards.
We rarely see so much impact with so little effort. Sometimes, it needs a third person (outside the operative gravity) to move the obstacles.