Whether you’re undertaking a first-time implementation of the OpenText Documentum for Life Sciences Quality and Manufacturing solution or you’re migrating to the platform from another software solution, you’ll want to employ a best-practice-based approach to ensure you’re setting up your organization for a stress-free implementation.
After all, the sheer volume of content can be overwhelming and the potential to change business processes that developed over time can be a contentious point in any organization. This planning checklist can assist in making the transition as painless as possible and put your organization one step ahead in planning and implementation.
Misalignment of teams and failure to meet project goals and timelines are an all-too-common problem with big technology projects. Many life sciences businesses have gone through this experience when deploying, migrating, and managing Electronic Document Management Systems (EDMS) and the ancillary systems they support.
Typically, teams or committees are created across different business units and geographies, each with different goals and expectations.
Markus Schneider, Managing Consultant and Life Sciences Expert at fme AG in Frankfurt, is one of the leading migration specialists in Central Europe. He is leading a team of application- and content-migration experts focused on the Life Science and especially the Pharmaceutical industry.
Whenever you start thinking about data migrations, it’s almost impossible not to jump to all the potential challenges. Even the most well-run projects can be derailed at any point. That’s because most migrations are often complex efforts that require detailed planning that takes into account how users are going to conduct business during the transition phase without the pain can frequently accompanies the migration.
It’s all about how to transition data fast and securely with minimal downtime or disruption to the organization and employees. But that’s much easier said than done in most environments – especially when you start thinking about the scale of content to be migrated and what’s technically required to make content “discoverable” through search so users can locate their documents quickly.
Networking and learning from the experiences of other organizations is integral to business growth. That is the primary objective of the one-day Life Sciences User Forum (LSUF) meeting sponsored by fme and OpenText.
The meeting held in April brought together business and technical leaders from within regulatory affairs, quality, and IT to share their experiences with regulatory content management strategies, technology implementation challenges, and leveraging next-generation digital tools to automate and improve business processes.
At the end of August I was able to attend the BoxWorks conference in San Francisco, subtitled “The Future of Work”. I have to admit, I went there with only a little pre-knowledge and with the history (baggage?) of being a long-time Documentum consultant.
Let me start with a quick summary of the highlights:
Box Feed (available as Beta)
Box feeds allow you to get a stream of activities happening in the shared folders which the user can access. This is a nice collaboration function as are you are seeing the content of your coworkers directly in the stream. This has been missing for a while and Box is now delivering a first iteration with the possibility for you to comment on the documents.
It’s been very interesting to watch how the Cloud has had an impact on Enterprise Content Management in the Life Sciences market over the past year or two. I doubt that there are too many observers with knowledge of the market that believe that its impact has been anything other than positive. But as with most “no brainer“ disruptive technologies, it’s still finding that the path to adoption is not quite as simple and straight forward as it might at first appear.
Clearly, the opportunity for Life Sciences companies to outsource their IT infrastructure and some related services is a derivative benefit of utilizing Cloud. In addition, subscription pricing, synonymous with Cloud solutions, has the benefit of moving CapEx to OpEx and realizing the financial benefits of doing so, appeals to many companies.
OpenText Documentum is a full-fledged and mature server-based Document Management System which is accepted e.g. by the FDA and therefore widespread in pharmaceutical companies.
Compared with cloud computing technologies that are very strong in providing elastic (scalable) services OpenText Documentum products could be regarded as inflexible and monolithic / layered applications. Although they seem to be the exact opposite of the flexible Microservice architecture approach used for cloud native application design, there are ways to combine OpenText Documentum products with cloud computing technologies.
I usually write blog posts about general IT trends and about the paths and aberrations of digital transformation. I have always avoided writing articles about us, fme AG. Today, for once, I want to break that rule. Sometimes you walk out of a customer meeting and ask yourself: “What in God’s name do some so-called cloud consultants tell clients? Why are they confusing their clients more than neutrally showing them the options for the way to the cloud?
The list of ways a company can leverage its applications into the cloud is long. Thus also a term variety prevails which is confusing.
Containers, here I will call them more specific Linux containers, are in short modularized software installations. Think of a container as an isolated area with a self-contained service. The container consists of all dependent software the service needs to run. Each container / service can connect to other containers / services. Because the containers are isolated to each other, they are not able to interfere with others in terms of software versions and runtime behavior. For each container you can plan separately on which Linux operating system, web server, language interpreter, etc. your service will rely on — which best fits to your needs. That means, that for example for excessive use of threading or performance needs a single service could be written in Go Lang based on Alpine, while another one uses Apache with PHP also on Alpine and a third one needs to comply with prerequisites using Tomcat with Java on CentOS. All this is possible with containers even running on the same host.