Having just finished phase I of my eResume website, I was given cause to ponder the debate that you will hear around IT systems in most industries, but in particular in the pharmaceutical business. Do you buy a solution, or build it yourself. My website, as it turns out (and yes, it is very basic) consists of some built elements and some third party components.

It turns out that this was the best solution all around. While my javascript isn’t too shabby, it was much easier to locate a library that provided the functionality I needed. At the same time, I built my own style sheets so that things would be positioned the way I liked, and styled to my tastes. I could download a very complex style sheet, but then I’d have to figure out what combinations of styles would work to give me what I wanted, and suddenly the project would get to be a bit much. Similarly, my webhosting company recommends a php based form management tool for contact forms, and the like. However, there was simply too much functionality that I would have had to spend a couple of hours figuring out, vs. simply downloading one of the flavors of the FormMail Perl script from the web. In the Pharmaceutical systems sphere, you run into many of the same challenges. My deepest experience is with LIMS selection and development, so I’d like to reflect on these questions with regard to LIMS.

The preference, in my experience, has been to opt for the purchased solution. The greater the out of the box match with our operations, the better. Minimal configuration, and no customization. This is based on a sentiment you will often hear, and I’ve often said, over the last few years, that in the pharmaceutical industry our job is the manufacture of drugs, not IT systems. I hope to blog on this more in the future, but it occurs to me that we are, too, in the business of IT system development. The modern pharmaceutical company can barely operate without robust IT systems. So, it is, in fact, a part of our business. We therefore, need to be less hesitant to explore a build solution.

Early in my career, working for a small startup, I had limited staff, even more limited budget (not to mention limited off the shelf tools at that time), and a big job to get done. The natural solution was to engineer and build my own solutions. Those solutions lasted for well over a decade (with a major overhaul of all of them at least once). Because I ran the operations the tools were designed to support, there wasn’t the typical requirements headache that goes with system design and build processes. Over time, a member of my team and I attended a course on tech writing so we could develop top flight owners manuals, and we subjected the systems to a very rigorous validation process which helped us tighten up the systems even further. However, even in that environment, the time came to consider switching to more off the shelf solutions. The rationale is that these would, in theory, be easier to manage as we wouldn’t be responsible for coding, bug tracking and fixes. Also, as the supported departments were expanding, and we weren’t, our capacity to build new functionality was greatly limited. Of course, we still had limited budgets, even for system acquisition, so we tended to acquire purely off the shelf with very minimal configuration options. Because the solutions were completely off the shelf, they didn’t fit our operations very well. I’ve never seen an off the shelf pharma system that did that very well at all. One system was so unpopular that the “receiving” department (as in, receiving punishment) refused for a couple of years to give up the old system. On one occasion, I was able to identify a system with a significant amount of out of the box functionality, with limitless customization options, and a good price tag. Unfortunately, the fact that we would be the first adopter in our industry made the selection unpalatable to certain key individuals, and the system was never acquired. The alternative we were forced to implement was a narrowly focused solution, that was never very popular with it’s users.  When it came time to expand to additional groups, it didn’t fit.

In later years, I had an opportunity to be involved in the selection and implementation of systems that ran from customizable to configurable, and all with less than optimal success. Certainly, some of the difficulties were with the requirements process. In particular, the lack of willingness to execute business process evaluation, and re-engineer where necessary, is always troublesome. However, there were other more challenging issues. For the highly configurable system, we had a system with a sound data model and a pretty robust set of business logic. However, the interface was very outdated, and there was literally nothing we could do about it. The interface difficulties really render the system very unpopular with significant portions of the user community. All of the vast configuration options had to do with business logic and data models, and virtually nothing to do with the interface. The highly customizable system had an extremely complex development environment and some companies, in order to make things work properly, hired vast teams of developers. Of course, backing out those changes during the system upgrade, was nearly impossible

What was interesting is the system I mentioned earlier, that had nearly limitless customization options, was that such customization would be possible by smaller teams of developers, and would be much easier to accomplish. I think therein lies the sweet spot. Although most pharmaceutical companies have similar systems, they are not identical, and some customization (especially around interface design) is likely warranted. Further, the most ideal situation is a system with a robust API. This would enable the development team to create a layered (wrappered may be a better description) system where if the underlying system is modified may not result in much if any impact to the custom piece. The only remaining danger is for the development and maintenance teams to think that once delivered, further customization will never take place, so no allowance is made to support that activity. You would think that this is self-evidently an erroneous view, but it is not uncommon. Even predominantly off-the-shelf configurable systems suffer from this belief system.