Planning your Migration from Perceptive Content to OnBase by Hyland

John Marney:
All right. Hello everyone, and welcome to yet another RPI Consultants Webinar Wednesday. Today our topic of discussion is around planning your migration to OnBase. This webinar is going to be largely a discussion around migrating from Perceptive Content to OnBase. However, a lot of the topics we discuss are general advice in decisions and planning for any type of system migration. So, definitely a valuable advice. First, a few housekeeping items. Of course, the webinar will be recorded and posted on our website pretty soon after we’re done here in the next couple of days. The site deck will be shared to all attendees, so don’t feel like you have to speech out everything. Of course, we have someone standing by to answer questions, so please feel to get into that go-to webinar window and the questions playing there. Type up your question and submit it.

Of course, if you have any ideas for future webinars, any content that you’d like to see, we’ve got OnBase content planned for the rest of the year practically, but if there’s any topics you would like to see, please, please let us know. And finally, this is the first in a series of two webinars today. This afternoon we have a webinar on process automation in the manufacturing space. So, if you’re in the manufacturing space or even if you’re not, feel free to join that to pick up some valuable information, and that is at 2 o’clock Eastern.

So, let’s get started. This is just another webinar in a long series of webinars around OnBase Content. The webinars we’ve already done are available at rpic.com/webinars. We did one around just a very high level “What is OnBase?” introduction that goes over some features, has a small demonstration of the product, and then we did a two-part series on a direct comparison between Perceptive Content an OnBase. Both of those are available. Upcoming in the next few months you’ll see a webinar around diving a little deeper into OnBase modules and features, going into some of the really cool things that OnBase can do. We’ll be taking a look at the OnBase supplier portal, a really cool solution that is often requested, and then well also look at the Outlook Client, which is very future-rich.

Many of you know me already, but for those who don’t my name is John Marney. I’m the Manager of Solution Delivery here on the Imaging Team at RPI Consultants. That title is just a fancy way of saying “professional CAT herder” for our team of consultants and developers. I have over seven years of ECM and OCR design implementation experience. Largely spent time in the accounts payable processes for a lot of healthcare organizations, and as of very recently I am now an OnBase-certified installer, so definitely keeping up with my training there. Today we’re going to talk about migrations where we’re going to dive into a few different subtopics there. First is our considerations around some specific items, documents, workloads in the migration process.

Then we’ll take a look at some broader strategies for how you can approach a migration project, and then finally an even more high-level project plan, a sample project plan and some more information around some things surrounding a migration project. So, first a little bit about RPI. For anybody who doesn’t know, RPI Consultants does work in a lot of different software spaces. Obviously the Imaging Team here based out of Kansas City focuses on the Perceptive, the OnBase, the Kofax KTA/KTM, Kofax Capture, the imaging components. The majority of RPI Consultants focuses on import, loss, and consulting. Obviously, our core competencies are solution design, business process automation, managed services and product support. We do a lot of software upgrades on all aspects of the business, so anything in the software environments we can handle.

All right. Let’s talk about some migration considerations, some specific questions you can ask, and some advice from RPI about how to approach. A quick disclaimer, RPI Consultants is a Hyland partner. We work very closely with them on the migration planning, any potential automation around this. So far, everything that you’re being presented today is true as of February 2018. However, we stay in close contact with Hyland. Things may and probably will change down the road, so please reach out with any questions around how things may have changed. First step. Obviously, before you can implement anything in OnBase you have to look at getting it licensed and installed. The first question I actually have to ask and find out is, does your organization already own OnBase? This may seem really silly, but larger organizations may own one, two, or five different ECM platforms.

If you’re a large university or a large healthcare system, especially a healthcare system, you may already have OnBase for your clinical components and have been using Perceptive for your back office. Definitely a possibility. This is important not just because you may not have to have that initial license expenditure, but you want to be sure you’re not impacting any currently live solutions on those target platforms as you plan your migration. We’ll be talking about the actual … There’s three main components that you want to consider. This is how we’re breaking down a migration project. You want to look at the actual document conversion itself, that’s step one. You want to look at the workflows and processes and how those will migrate to the target environment, and that’s step two. And then you want to look at your custom integrations or custom development, and that’s the third point.

First, document conversion. When we’re talking about document conversion to the target system, this is talking about tasks, folders, drawers, custom properties. Anything around the archival or retrieval of documents and the actual document images. Typically what this is going to look like is a two-step process. First you’re going to set up a mass … documents from Perceptive Content with their indexes. Probably going to utilize a big index file to get that information. Step two, then, is to take that storage medium, plug it into OnBase and do an automated import so you can pull those documents into OnBase. You have to have your document types and keywords set up already, but once those are configured we’d set up the import and it can just run.

This is a lengthy process. Some organizations have tens of millions of documents in their system, so if you are in one of those organizations that’s up in the millions, consider that this is a multi-day process more than likely. It may be tempting to consider automating this step, and it is possible to use the various integration servers or web services to do an automated export/import into another system. However, that’s adding quite a bit in the way of technical risk to the document migration. That may not be necessary.

Speaker 2:
John, we have a question. Tim asks, can you talk around how the annotations are going to move for documents in Perceptive going over to OnBase?

John Marney:
Absolutely. That’s a great question and that’s on my next slide. A few questions to ask yourself for your document conversion. Number one is obviously, “Do I need all my documents?” In many cases organizations may choose to leave the Legacy system in place. And so, if you want to go down that road you can leave the Perceptive environment, leave the documents in that environment and only do new documents into the target system from that day forward. However, going with the assumption that you will want to migrate some or all of your documents to the new system, the next question is generally going to be, “Do I need to retain my document annotations?” You have some options. Most businesses that use annotations as part of their business process whether it’s a stamp, … e-note, you will want to retain that information in the target environment.
The typical process for annotations to be retained is to use Output Agent, which you would need to be sure that you own. But Output Agent is used to export documents en masse and flatten those annotations onto the document image. That is the best practice way of doing it. If you absolutely need for business purposes those annotations to continue to live as a separate object on top of that document, and sticky notes to be retrievable in the same way and added to, then we would need to look at some more creative solutions. It is possible to migrate to the target environment, but you’re going to significantly increase your technical risk in doing that. Similarly, the final question is going to be around, “Do I need to retain in my document … data and/or my workbook history?”

These are going to be things like the user who created the document, the date that the document was created, tasks, workflow history, what queue it was in and when. The default is going to be that this information is not transferred to the target system. If you output a document from Perceptive, almost all of that information is going to be lost. There are some approaches for simple data, like Creative Data or Creative User. We could add that as an added data field in the OnBase environment, so that’s not too difficult to retain if it’s needed. However, workflow history is going to be a challenge, and again we have some creative solutions on how we can retain that. We could append it as a page on a document, we can make it searchable via XML, maybe even plug it into Enterprise Search so that those documents are searchable by their workflow history.

All that being said, those are things that we would need to really deeply analyze and identify if they’re really a requirement, because that’s going to up the level of effort pretty significantly. For your document conversion, a few pieces of advice. Number one, and I think this is probably the most critical, implement and execute retention policies. I can’t tell you how many implementations I’ve done where the business is all too willing to kick the can on implementing the retention policies because, “That’s five, seven, ten years down the road. I don’t need to worry about that right now.” Well, we’re now five, seven, ten years down the road, you don’t have any implementation or any retention policies, and documents are building up in your system that you do not need to store anymore.

Retention policies can be used to move documents to cheaper storage, or delete them entirely if you don’t have a need to retain them. This is going to trim the fat, so to speak, on your document to move less to the target system. The side benefit there is also it could help you identify document types, drawers, custom properties, folder structures, everything else that goes along with that that are no longer needed because you don’t have to support those types of documents anymore. You don’t need them. Really it’s around identifying, especially in an older environment with many different solutions, identifying what you don’t need.

The second item, remove duplicate documents or unnecessary records. As part of various business processes, we may have decided to store duplicates purposely, we may be storing them accidentally, we may have extra pages appended to documents such as bar code separator sheets or something that we had decided to keep at one point but we really don’t need as part of that document. Trimming any of that out, anything that we can identify to narrow down the scope of our document conversion will help.

Finally the third item is really just the overall footprint of your documents, and this goes into the entire conversation about trying to narrow down the scope of it, but reduce our document file sizes. If you’re storing large file sizes, large PDFs, Word documents and things like that, take a look at whether that’s absolutely necessary, and whether we can do a conversion project beforehand to get everything into a TIP file or TIP image, which would significantly reduce those file sizes, therefore speeding up our conversion.

Speaker 2:
Teresa had a question about, during the conversion what about the documents that are still within workflow being processed? How do we handle that?

John Marney:
Also a great question. I am actually going to address that here shortly, but the short answer is, we want to get them out of workflow if at all possible. Our next topic actually is the switching to workflow and process overview, or an overview of our workflow and process migration. Okay, get it out in the open. Bad news. All of your workflow processes will have to be rebuilt in OnBase. We are essentially re-implementing everything that you’re using right now. This includes rebuilding annotation templates, routing rules, e-forms, i-Scripts, all of the things we have already talked about for document indexing structures and things like that. All of these are going to have to be manually configured. There is not a way to automate it, and our understanding is that most of this is probably not going to be able to be automated or not worth it.

However, there are some good news. Having to rebuild this offers us the chance to redesign our processes anyway, to potentially make use of additional features that OnBase has that maybe weren’t available on Perceptive. And the other piece of good news here is that OnBase has a lot of features that allow you to configure things that had to be customized in Perceptive. So, simple e-forms can be created really quickly in OnBase. Many actions that you had to create a custom i-Script for in Perceptive can be done inside of the management queue in OnBase, so the necessary new development may not be as much as it was the first time around.

Some questions around the workflow migration that you can ask yourself in preparation. Number one, similar to documents, do you need all of them? Do you need all your workflow processes? It could be that entire processes were used years ago for capturing and indexing documents that are no longer needed. You may have whole sections of existing workflows that you don’t use. I can’t tell you how many help checks I have done for our clients, and I’ve identified that half of the queues inside of their accounts payable workflow aren’t being used for anything. Maybe they’re storing documents that just need to be archived out. So, identifying what those are is really important so that when we go to implement the new process we have trimmed out anything we don’t need.

It’s important for you to identify what custom scripts or e-forms can be built within OnBase and which may rely on custom development. What I mean by that is, most scripts that are doing, let’s say, a simple document re-index, maybe they’re doing a quick database lookup. In a human resources employee file scenario you’ve got an employee ID and it’s looking up the rest of the employee information to attach to that. Those kind of things can be done inside the queue. You don’t need custom development necessarily for it. More complex forms that do a lot of look-ups and have a lot of custom logic may still require custom development.

One other consideration that only is going to apply to some clients is that if you’re doing any sort of approvals in Perceptive right now, whether that is task-based or [inaudible 00:16:48]-based, or … Workflow base or what have you, right now to … an Excel spreadsheet. The ideal scenario is to get that information in your ERP, leverage existing hierarchies within the organization to drive those approvals. However, if you can’t do that or you can’t implement that in the meantime, because that is a challenging thing to do, OnBase does offer an approval manager. So, this is something that will have to be translated. You want to be sure that you have that as up to date as possible, and that’s something we can build into your OnBase workflow.

A few pieces of advice on the workflow migration. Number one, get … Check, optimize these solutions, do whatever it takes again to trim out the unnecessary components in your workflows or again potentially even unnecessary whole workflows. The second thing is, and this is to answer that question, process all documents in workflow. Because the document conversion process is something that is probably done in steps and probably done offline, you ought to be sure that everything in your workflow … And this is going to be during the migration project, not really during the planning phase. We want to make sure that everything in workflow is processed through, that you don’t have anything lingering. And if there is a need for some sort of … In some projects there may be a need for some concurrent workflow. We want to try to avoid that, but if we have to we can handle it.

The third recommendation is, absolutely be sure you have your documentation in order. And what I mean by this is mostly being sure that you have a written version of your workflow. This is generally a series of Visio diagrams showing your business process end to end, how users interact with the system, and that includes all of your routing rules and iScripts. What are the decision points? Because if we have all of that documented it’s very easy to translate into a design document for OnBase. The third main section of considerations in a migration project are going to be around your custom integrations and development. This may be anything from reports, to database look-ups, to on-service calls, anything like that.

Again, as I mentioned on the workflow piece, custom development such as e-forms and iScripts are not going to have an automatic migration. Most of those things that have been custom-developed have again custom code, not easily translated. Some things will change in your integrations and some things won’t. For example, URL-based integrations for document viewing, such as WebNow link from your ERP, obviously if WebNow is gone and you’re intending to get rid of that Legacy system and convert those documents to OnBase, the OnBase has a similar feature but the link syntax changes completely. So, that’s something that would have to be updated in your ERP.

Other things that will change, in-bound web service calls, so anything coming into the system. If you’re using integration server calls and Perceptive right now, that all completely changes. Things that should not change or should not change the configuration endpoints, ERP look-ups and inserts or if we’re interacting with an ERP table, you should not have to change anything about that table structure, that’s all customized in OnBase. Any outbound web service calls. So, in PeopleSoft we frequently do a voucher bill via a web service call. Obviously, that web service is meant to be used across different systems. We should be able to integrate with that without any changes. Things like that should not need to change.

Moving into a little bit around migration strategies, I think I … Sorry. I wanted to talk a little bit about the complexity that different solutions may offer. Now, it’s very important to keep in mind every single one of you, every client, every implementation is very unique. These are some very generic ideas based on some best-practice implementations, but obviously to determine the level of complexity of your migration you’d absolutely need to sit down and do some analysis to identify your specific requirements. But in general on a less complex side are just processes that don’t have a ton of steps to them, so typically a human resources onboarding or an electronic employee file is some straight document capture. Setting that up to a new workflow is going to be fairly easy.

The conversion is probably the harder part there if you want to move your documents. Or very easy processes are your Learn Mode-based workflows. That’s your typical scan-and-link is what they’re often called, just capturing documents, quickly indexing them and archiving them. There’s no real processing. Those are going to be very easy to migrate to OnBase using App Enabler for a very similar look and feel for your users.

On the middle third of the complexity are healthcare implementations. These we are considering you would potentially not have a document migration, so if you’re using … Interacting with Epic right now, we would typically look at only updating the links in Epic for new documents, and leaving Perceptive in place as a Legacy document archive so those documents can still be moved or retrieved out of Perceptive if need be. That significantly minimizes the risk of healthcare migration. However, some organizations may elect to go ahead and move all the patient data into OnBase. That would move this to the more complex end.

And then the probably most complex solutions to migrate are going to be your back-office AP, where we have a lot of automation. This is invoice processing and approvals with OCR, Brainware, Kofax, using an e-form, maybe even a custom e-form with your customer approvals and a lot of different ERP integrations. Not only do we generally need to consider document conversion as part of this, actually implementing that future workflow may be almost as much work as the original implementation.

Switching gears a little bit I’m going to take this a little bit more high level. We want to talk about some migration strategies. Again, we’re talking mainly about migrations from Perceptive to OnBase, but again these ideas would apply to any migration on our Enterprise platform. Again, I want to remind you that every client, every implementation is unique, so these are just some very general ideas. Regardless of what approach you take to migration, you might consider starting with a pilot project. A pilot project would allow you to get your IT and infrastructure expectations in place, and it would be a less intense learning curve for users and your organization as a whole.

So, if you are already planning some sort of department expansion you need to implement accounts payable in your organization. This is a good opportunity to implement it in OnBase instead of your Legacy platform, and therefore get everyone used to it. Now, the downside is that of course the longer you go with that Legacy system in place, your IT and infrastructure is now supporting multiple systems, so there is a risk there as well. But as far as your overall strategies for migration, the first option is really just a based approach. Migrate some workflows, some documents, do these in chunks typically by department. This is going to probably be the preferred approach for most organizations who have multiple different solutions inside their environment.

If they don’t interact with each other you have the option to move some users at a time, reducing the risk to your business. This also simplifies the resource planning and the individual requirements for that solution. It does not have the complexity that the next option has, to review it all at once. An all-at-once approach is the kitchen sink. You migrate all workflows, all drawers, all documents. It’s generally not going to be recommended for large organizations with multiple departments. However, if these different solutions have a lot of crosstalk, then you may have to. This would require substantial planning, something you definitely want to have a good plan in place for, and would require the support of all the businesses involved.

One option too, as we’ve discussed, is to continue to utilize Perceptive or your Legacy system going forward as a Legacy document archive. That means you would migrate workflows only and for a day forward processing new documents would go into OnBase. Like I said, Legacy documents that remain in Perceptive can be looked up there. The benefit here is that it retains all of your workflow history, your metadata, every feature that Perceptive has with those documents is still there, and this would minimize the requirements needed for that Legacy support during the conversion.

So, something I’ve touched on, any migration project is inherently a little bit risky. On one end I think that you’re either trying to focus on … You have a little bit of a dilemma on whether you’re trying to focus on least impact to users and the business, or whether you’re trying to focus on the least technical effort. Use of this option can be minimized by increasing the technical effort, the planning, the requirements, and vice versa by reducing the requirements or technical requirements of the project you may impact users by not having everything there that they would potentially need. This just requires proper planning to identify the requirements of your organization, and a discussion with the business users and with your IT staff.

Migration project planning. Just a high level of what a migration project should look like in the end. Migrations are a lot like a brand-new implementation, and right now I’m displaying a chunk of a high-level project plan for a typical implementation. If you were coming into this never having done a business process automation or having ECM, we do our design, get everything documented with the future state, your future state process flows, implement, do any custom development we need, move into training, get your users testing the system and comfortable with everything. We take you live, we’d be supporting you, and that’s it. A typical implementation project.

Well, in a migration there is a couple of phases that need to happen upfront. First is our analysis. We want to do health checks on the existing system to identify any weaknesses, identify your requirements, optimize the solutions and systems before we ever think about a migration. And these are important to do anyways. The benefits of optimizing any existing solutions are there even without a migration. The next step is to actually focus on your documentation and your readiness, so you want to get everything that you currently have documented, current state, so that when you move into that design phase it’s a very easy translation. And then at that point in the planning phase you would secure licensing, get the product installed, and things like that.

Keep in mind that also running concurrently with a lot of these phases it’s almost a separate project. You got the Legacy document conversion should you choose to do that. So, there’s concurrent efforts in implementing the processes and implementing the document conversion. And throughout the process you’d need to consider the needs of that Legacy system. So, throughout the project of a migration, whether you do it in phases … Or especially if you do it in phases but even if you do it all at once, you need to consider the support and maintenance of that Legacy system. You may be wanting to train up your support staff on OnBase, or bring on resources for OnBase, and want to remove attention from Perceptive. So, it’s something to consider.

What can RPI do? Obviously, we can assist you with this end to end. We can develop project plans and bring in our project management to put together a plan of action for you, a roadmap if you will. We can provide technical strategy and architecture for your future state. Obviously, the biggest thing upfront is our migration and/or conversion analysis. So, doing those health checks, identifying what licenses you may need in a future state, optimizing the system, getting it really ready to be migrated. Of course, as I discussed, Legacy system support. We’ve had people bring us in to just take care of it, and babysit and administer that old system while their staff moves onto the new one and vice versa. We’ve been brought in to assist with OnBase and the new implementation while the existing staff focuses on the Legacy system. So, there’s a lot of options on what you can do there.

In summary, I think the main things to consider are really with any project, plan early and you want to be sure you develop a roadmap for your organization. So, put something on paper in place about the way you want to approach your migration. And the other main thing is, as I’ve said throughout this … that prevents us from having to do anything … Doing too much in the future state. That’s it. Any questions?

Speaker 2:
This question is from Teresa. Are there any space concerns with migrating over to OnBase, or is it kind of the similar situation from Perceptive Content?

John Marney:
Generally, your space in terms of your … what takes up the largest amount of space is your file repository. The file repository will largely use about the same amount of space. There is, I believe, a sizing calculator available from OnBase, so we can use that if need be. Generally you can expect, I think it’s something like 50 kilobytes per black and white TIF page. However, it should be roughly the similar in a conversion. But that’s where it comes into the … in that document conversion process with a … storing anything in the Legacy system that is taking up a lot of space, we want to identify those and convert them down to a smaller file size if possible to reduce that footprint.

Speaker 2:
And this question is from Cheryl. Are there any pre-built conversion tools that Hyland offers to help with this process, or is it a manual thing?

John Marney:
As of right now, no. And in my conversations with staff at Hyland and honestly just as an expert in these systems, we’re unlikely to see much in the way of automated conversion tools. Because implementations are so different, I would have trouble seeing the value in the time that would take to build those tools. The only thing I could see being built would potentially be something to assist with the actual document conversion, make that speedier, more direct from system to system. But frankly, things like your workflows or your iScripts, I can’t envision a time where there will really be a way to automatically create those in the new environment.

Speaker 2:
This question is from Stephanie. You mentioned piecemealing the conversion, kind of once solution at a time. If you have four departments, documents all shared in the same LSM, how do you recommend that approach?

John Marney:
That’s a great question. That’s part of the reason why we would use the API to export documents and not try to grab them out of the file system or anything like that. Through the API we can say, “Okay, grab documents out of this drawer for this department and export all of those.” And at the same time we can … Once we’ve validated that export we can actually remove them from the Legacy system. That’s a great topic of conversation that may lend itself to something much longer, but … And OnBase it’s very typical to separate on the file system your different departments and your different groups of documents, whereas in Perceptive using OSM Transfer, OSM Grouping, we can do that but it is not typically implemented. We would typically use the API to retrieve documents and remove them once we’re satisfied.

Speaker 2:
This is a pretty popular question. If you are on 6.7, heading towards end of life, what’s the recommendation through the upgrade there? Do we upgrade to 7.2 and then move onto OnBase? Is that a requirement or can we just go straight to OnBase?

John Marney:
There are a number of considerations there. If you’re on 6.7 right now you are facing an expenditure just to get up to date. So, you should be able to calculate that into your ROI to determine whether it’s worth upgrading or worth migrating. There is no official license discount. There is no official conversion path. Moving to OnBase is entirely something that you’ll have to identify and something we can help you identify as being worth it for your organization. So, on top of that, whether that ROI exists right now in an upgrade, identify whether there is any other departments you’ve been planning on implementing it OnBase or in your current system, which could then also lend itself to the fact that if you only want to implement it once if possible, do it in OnBase if you can. That’s your perfect pilot project.

Speaker 2:
Another popular question. Is the OnBase migration mandatory? If you are happy with Perceptive Content the way it is right now, is there an urgency to move over to the new platform?

John Marney:
Great question. It is absolutely not mandatory. The current roadmap that Hyland has provided publicly for Perceptive is that we will continue to have releases. They’ve publicly stated that those releases will be very light on new features and will generally be geared towards a few specific features that they’ve already had on the roadmap, and bug fixes. So, we anticipate a release in … I think it’s Q2 of this year of 7.2.3 and anticipate a release in the same time in 2019 of 7.3. That roadmap may alter or shift, but that’s the current public plan, which means that in every new release that end of life for the product is getting pushed out. So, the product will continue to be supported. We absolutely encourage our clients to continue to invest in the platform if it makes sense. There will be times where it stops making sense, because there will some day likely be an end to the system, but we’re not anticipating that in the near future.

Speaker 2:
You mentioned in your migration strategies that there are instances where we do need to keep Perceptive Content and OnBase live at the same time. Is that required? Is there any way to do this without having both systems concurrently running?

John Marney:
Absolutely. It would not be a best practice to, I think, leave them both running simply because from an infrastructure standpoint for practical reasons, not quite knowing where to go for what type of document and that kind of thing, it makes more sense in a large number of cases, to do the cutover. It’s technically challenging but it can be done. There will be some instances where, because a document conversion would take too long to satisfy business requirements, those documents have to be available. Oftentimes in a clinical healthcare setting for patient records, we may want to leave that Legacy system online for document retrieval, and maybe evaluate a conversion later or do that as a separate project.

However, even on top of that I’m sure that we will encounter situations where organizations want to have simultaneous workflows. That is absolutely a bad idea and will be very difficult to manage, but it can be done and generally it will have to be something, I think, where … when a workflow is accomplished in the Legacy system, that that information is continually migrated to the new environment.

Speaker 2:
Can you talk a little bit about how the Learn Mode application plans get migrated over into OnBase and what that looks like?

John Marney:
Sure. Absolutely. Learn Modes, there’s a variety of different Learn Modes in Perceptive. Generally what they do is they scrape data whether programmatically or even just through a screen shot out of your line of business application, and then pull that data into index keys in Perceptive. That technology changes. It’s very similar. It’s called App Enabler OnBase, but generally it’s the same idea where you point the application to certain spaces on a webpage, your loss and your SAP, etc., and it retrieves information and it applies it to the documents in OnBase. So, they’ll have to be manually rebuilt because many Learn Modes are heavily customized with scripting. None of that will translate to OnBase, but the essential idea will remain the same, where data can be scraped out of a system and applied to your documents.

Speaker 2:
Following up on that, within Perceptive Content we you use something like a OSM redirection where we store files into different OSMs. Is there something like that for OnBase as well?

John Marney:
Yes. And that’s what I was referring to previously. That’s actually a best practice in OnBase. You generally would set up separate shares for the different departments when you configure it initially. Oftentimes that OSM rotation or OSM split isn’t set up for Perceptive clients. It’s just not a practice that we’ve typically gotten into. So, yes, that is absolutely something you can do and we typically would do in OnBase.

Speaker 2:
Can you talk a little bit about the main differences between the integration points within Perceptive Content and OnBase, specifically around customized scripts, external message, workflows?

John Marney:
Absolutely. That’s an extremely broad question, so I’ll hit some highlights and if you have more questions on it we’d probably need to sit down and have another conversation or maybe even a topic for our webinar. So, iScripts, which are your most commonly used, commonly developed custom workflow driver in Perceptive, those are something that will have to be rebuilt in OnBase. As I’ve mentioned, many of those actions such as reindexing documents, doing database look-ups, won’t have to be scripted in OnBase. Those are something that you can do inside of the queue. You say, “I want documents to be re-indexed, I want to do this database look-up.” It’s a lot easier to configure. So, iScripts in general will go away.

Now, for some deeper integrations OnBase does have its own scripting library. It’s called the Unity API, and that is also code. It’s a different kind of code, and there will be some of that probably necessary for more complex integrations. You’ll still have the same concept of needing to customize your workflow. E-forms are similar in that the way that they’re built in Perceptive many e-forms may not need to be custom built in OnBase. Many of them can be built using a form builder, but the more complex ones will still need that custom development. The other big one is integration Server. Integration Server and Perceptive allows inbound calls to Perceptive to do things like retrieve documents, create documents via workflow items and things like that.

OnBase has its own Enterprise Integration Server, a completely different technology though. All of the calls will change. It also allows outbound calls from OnBase to other applications. Finally, External Message. Currently we use External Message in Perceptive to queue up messages and cause that to trigger other actions, generally in iScript. That similar idea will probably be used in an OnBase implementation, but that’s something that … External Message is something very specific to different solutions in Perceptive. Depending on the solution that will change how we will go about that in OnBase. But there is still always going to be some sort of idea of queuing up messages to trigger more actions inside of your workflow. Great question. Again, if you have more specifics we can really dive into that.

All right. It looks like that’s all we have. I’m sure there’s more questions. Feel free to shoot us an email. You can reach out to us anytime, and thank you very much for joining us. And again, please, please shoot ideas for future webinars our way. I really want to present the content you want to see, as technical or as high level as you want. Also, please join us for our webinar this afternoon a 2 Eastern.