One of the philosophies I have developed over the years is the separation of applications and their image repositories for every application developed. I build a storage volume and a storage class incorporating the volume for each individual application. These do not need to be physically distinct locations, they can be virtual names for the same location such as a Centera device or they can be two different folders on a SAN drive. The key is being able to reference them individually within the IPM product.

 The advantage I have found is if there comes a time when the images must be separated, or different purge cycles are desired, these actions can be accomplished from the standard Oracle IPM interface. Also, the individual application could be spun off into its own installation with some work by a IPM professional.

 The short term cost in time of building these extra storage class and volume references in my opinion is well worth the potential of not having limited your future actions with the system.

Jeff Doyle

Senior Systems Engineer

ImageSource inc

ProStor Systems sells a line of disk cartridge archival systems with some very compelling features. A representative of ProStor attended Nexus 2009 to demonstrate their systems, and as an Oracle IPM architect I was intrigued to see how well ProStor’s InfiniVault® would work in an IPM environment. So an associate and I visited ProStor’s headquarters in Boulder, Colorado with an Oracle IPM test system to put the InfiniVault system through its paces. 

We hooked up a direct network crossover cable to the archival system in the same NT Workgroup, and then attempted to configure IPM to talk to it. We found we had to set the IPM services account name and login to be exactly the same as configured in InfiniVault. Note that InfiniVault requires at least an 8 character password so the IPM services account must follow suit.

Once we had communication, images and universal documents flowed quickly into the archive system. Retrieval of objects from the archive system was very fast. We think setting IPM to archive older objects from expensive RAID 5 magnetic storage to InfiniVault can provide an opportunity to utilize the faster storage for current daily object retrieval, while placing less often accessed objects into long term storage. 

The ProStor system comes with a built in full text indexing feature we thought might be useful with IPM but unfortunately IPM stores all universal documents in a proprietary binary, with no file extension, which is what InfiniVault keys on to apply IFilters in order to index the data from many common file structures. 

InfiniVault also comes with a sophisticated records management capability but this can’t be used with IPM in any meaningful way due to the way IPM stores and tracks objects. However, the records management system could be used with many other common activities in an enterprise since InfiniVault can be used for all general archival tasks within an organization. 

Many more features are available with ProStor archival systems and we will be recommending them to our customers for IPM object archival. Feel free to contact me or  ImageSource for more information.

Clint Lewis
Senior Technical Architect
ImageSource, Inc.

  

Happy Thanksgiving

November 29, 2009

I would like to pass on a few fun facts about Thanksgiving.

Though it was not called Thanksgiving at the time, what we recognize as the first Thanksgiving feast was celebrated in 1621 by the pilgrims of the Plymouth colony along with about 90 Wampanoag Indians. The Pilgrims had suffered through a devastating winter in which nearly half their number died. Without the help of the Indians, all would have perished.

After the first harvest, Governor William Bradford proclaimed a day of thanksgiving and prayer to God. The food, which was eaten outdoors, included corn, geese, turkeys, ducks, eel, clams, leeks, plums, cod, bass, barley, venison and corn bread. The feast lasted 3 days. Though the exact date is unknown, the feast clearly took place in late autumn.

In 1623, a period of drought was answered by colonists with a proclamation of prayer and fasting. This prayer and fasting was changed to another thanksgiving celebration when rains came during the prayers. Later that year, Governor Bradford proclaimed November 29 as a time for pilgrims to gather and “listen to ye pastor and render thanksgiving to ye Almighty God for all His blessings.”

Throughout American history, there were many thanksgiving proclamations and celebrations. In 1789 George Washington proclaimed a National Thanksgiving Day on the last Thursday in November, in honor of the new United States Constitution. Thomas Jefferson, the third president, later discontinued it, calling it “a kingly practice.”

In 1863, Sarah Josepha Hale, the author of the poem “Mary Had a Little Lamb,” convinced Abraham Lincoln to proclaim Thanksgiving a national holiday. For the date she chose the last Thursday in November because of Washington’s proclamation. In 1941, it was officially changed to the fourth Thursday in November.

Since Abraham Lincoln’s proclamation, it has been a custom that all presidents of the United States make Thanksgiving proclamations every year.

Chris Sturiale

Training Manager

ImageSource, Inc

  

Every company no matter how big or small has an Accounts Payable department.  It may be as small as one person or it may have ten, fifteen or more people.  For medium and large companies there are problems that arise with the data entry of all that invoice data and the tracking of all those invoices through the approval cycle.  There have been many different methods that companies have created to try and handle both which still lead to missing/late invoices and mistakes during data entry.  Methods such as logging the invoices either in a spreadsheet or manually on paper are just some of the types of methods that companies have tried to keep track of where invoices are and how long they have been waiting to be paid.  Maybe there is a better way.

 Kofax KTM in conjunction with Oracle I/PM provides a solution to these two issues.  Kofax provides two software packages to scan and then process documents like invoices.  KTM is the processing part and is able to OCR and identify the key fields on an invoice no matter where on the page the data is located.  KTM can also validate some of the data against the ERP system the company is running. Fields like PO Number, PO Release, Vendor Name, Vendor Address, Vendor Pay Site, Vendor Payment Terms and other fields can be read from the ERP system and added to the set of data held by KTM.  KTM can then pass this data on to Oracle I/PM.

 Oracle I/PM is an imaging and workflow software package.  Not only does it store the invoice document with the index data entered through KTM, but it also has a workflow module that can track the invoice through the business process so the users can know where in the process the document is sitting.  With I/PM workflow the invoice can be routed electronically to the assigned approver for invoice approval that is done on a Form built for workflow.  If there are multiple levels that can be handled within the workflow in one of several ways depending on the information available from other systems such as the company ERP system.  In addition, I/PM workflow scripts allow a programmer to write code to transfer the data directly into the ERP system through its data import tables.  I/PM has been successfully integrated to pass data to JDE F0411Z1/F0911Z1 tables and Oracle EBS Open Interface tables to name just a few.  These code scripts are re-usable so we can quickly get them working in your environment.  Have we have found, not every company process their AP Invoices in the same manner, so each implementation we do is slightly different than any other, so we need to discover the differences and then modify the form and script code to match.

 We at ImageSource can provide the expertise and experience to quickly get an imaging and workflow process into place in your company.  Just contact us at http://www.imagesourceinc.com to find out how.

I’m always pleased when I can build a nice clean system for a customer.  I like to be able to look back and say, “That is beautiful.  I’m proud of that.”  Antoine de Saint-Exupery said, “A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.”  I like that quote and try to build systems with that in mind.  I like to be able to simplify a customer’s business process so it makes more sense to them that it did before.

But there is a danger here that needs to be avoided.  We are not dealing with art or literature.  We are dealing with business systems, systems that receive input from untrusted sources.  This data needs to be checked.  Joel Splosky puts it best when describing things you should never do.  He talks about old code that “has grown little hairs and stuff on it and nobody knows why.”  He’s not describing something beautiful; he’s describing something that works.  Something that’s gone through the pain of having exceptions found and dealt with.

Exception Processing

We help customers automate their business.  The software products we sell all have a type of workflow build it.  Oracle IPM and Liquid Office have a true workflow component where you build your processes graphically.  ILINX Capture and Kofax Capture have the idea of queues and the ordering of queues.  Systems with combined software are generally designed to be used in stages such as scan, store and retrieve.  In each stage the data is moved from one queue to another or one piece of software to another and the data needs to arrive correctly.  These are the types of system interactions I’m focusing on.  Unfortunately, these systems aren’t always configured perfectly and something will happen.

Evacuation Route SignYour scanned document will be unreadable.  Your form won’t be filled out completely.  You’ll have a power outage.  The database you rely on will have bad or missing data.  You network connection will drop.  You’ll need a strategy for handling these.

If you don’t handle exceptions well, your system will be consistently inconsistent.  Approvals will not be done on time.  Documents may be hard to find.  Users will become frustrated with extra unneeded steps to complete work.  Or worse, no one will notice until a year later and document XYZ is not in the system and the auditors that are in the room with you breathing down your neck lose their patience and your about to be sued.  You need to be able to handle these exceptions.

What An Exception Is Not

Just to be clear about the types of things I want to focus on, I’d like to list a few things I’m not talking about first.  When I say exception, I do not mean anything that can be considered a part of normal business processes.  For instance, in an accounting workflow, it might be part of the process to send invoices over $1,000,000 to a manager for special approval.  This is not an exception.  While the amount may be exceptional, the approval is a defined business process.  Conditional queues in your business process are also not exceptions.  If it is normal for a form to be missing specific data and there is a special queue for dealing with that, it is known and a normal part of the business processes.

What An Exception Is

Exceptions are when we are dealing with the unknown.  Exceptions are typically something that requires human intervention, special research or a new decision to be made that hasn’t been made before.  Exceptions are also when automated parts of the system suddenly stop doing the things they are suppose to.  (Actually, those are sometimes just programming bugs, but you need to handle those too.)

How To Handle Exceptions During Development & Testing

  • Build maps and scripts that contain catch all routines. If you have a workflow script that needs to interface with an external system, make sure you can accurately report that the system is operational, that you can connect, that you can do the tasks you need to and that it will return successfully.  All of these steps may need their own error handling code so you can accurately report the problem.  You may also want to catch other exception outside the known ones so that you can log and report on them.  Workflow maps contain exception processing within them.  Most queues can return with an error, which can then be routed to a special queue.  Be willing to add those exception queues.  Allow users to be able to route their data to these exception queues with explanations of the issues.  They may not be used much, but you’ll be thankful there were there when something happens.
  • Have good metrics and logging. The software we sell and implement already has logging features.  Those features need to be turned on.  When designing systems that have custom components, make sure they include a logging feature.  You will also need to make sure the data that is collected can be easily read.  This means investing some time into reviewing available reports or creating new reports.
  • Include automatic reporting. Consider an automated way to flag problems or issues that can be detected.  Emailing a business administrator or system administrator is a good way to alert people of potential issues.  Be careful with this, however, as you can have too much.  You want your noise to signal ration to be low.  The last thing someone wants to do is to read through hundreds of automated emails because perhaps one indicates an issue.  (There is a reason most people turn off the Vista UAC.  Allow? Deny?)
  • Test with real data. I’ve seen engineers send the same 5 documents through the test system thousands of times and declare the system is able to handle thousands of documents.  No, the system is able to handle those 5 documents.  That’s slightly different.  You need to test with thousands of different documents.  That is where your exceptions will be found.  You also need to test with real documents.  When some fills out a form for testing, of course they are going to fill it out correctly.  The programmer wants to make sure his code can read each and every field.  But what happens when they are not all filled in?  What happens when the data being used as a unique index is not there or not unique?  You need to test to find out.  Fake data will only test the common paths.  Real data will test for exceptions.
  • Test with a lot of real data. I feel the need to state this twice.  Exceptions happen when users are using the system.  Use the system as much as possible with real data before you go live.

How To Handle Exceptions During Production

  • Expect to find exceptions. Make it part of the production process to spend time looking at the log files and dealing with issues.  Every project our company manages includes what we call “rollout support.”  We know that exceptions are going to happen and we plan for the time to deal with and fix them.  Have someone whose job is to handle the exceptions from a business point of view, not just a IT administrator.  Give them the time required on a weekly basis to make sure the system is running smoothly, and that the users are happy with the way the system is running.
  • Be willing to change your process. After an issue occurs a few times, it may make sense to consider it something that should be handled as normal processing.  Be willing to review the workflow map or order of queues.  Those conditional queues I mentioned earlier, the ones I said weren’t exceptions?  Those are really exceptions that everyone already knew about.  Now that you’ve found and know about one more, add it to the normal business process.
  • Focus on the common problems. It’s okay to think, “This is the first and probably last time I will have to deal with this.”  As soon as the second time occurs, you need to plan to deal with more exceptions.

What To Take With You

By now you can see that your system is going to encounter exceptions too.  Your not alone.  We all have to deal with them.  You can see the importance of thinking about them, looking for them and dealing with them responsibly.  If you system is still being developed, you have the knowledge to be able to plan for them.  If you system is implemented, you now have good reasons to review and change it for the better.

I hope you can look at the design of your system and say, “The workflow map, scripts, queues and configuration may not be beautiful, but the system handles everything beautifully.”

Scott Hamilton
Senior Developer
ImageSource, Inc.

[photo by wikipedia user Patriarca12]

Business Process Optimization

November 14, 2009

For those of you who attended my breakout session at the NEXUS ECM Conference on automating business processes this topic will be familiar to you.  If you missed the session, this blog will provide a glimpse into the world of automating and optimizing business processes. 

There are many different ways to approach process automation and optimization and the purpose of this blog topic is to provide information based on my industry experience.  I will discuss identifying processes within an organization and then automating those processes utilizing a number of valuable implementation strategies.

Why Automate?

From my experience in the Enterprise Content Management industry, I have found the main reasons to automate or optimize a business process are as follows:

  • Gain Process Efficiencies
  • Process Quality Improvement
  • Improve Reporting, Tracking & Auditing

Process Identification

Let’s take a look at identifying a business process that could be automated.  When looking at processes to automate or optimize, the starting point is to identify a process and then extensively research the process to get a clear understanding of the current state.  A good place to start with this research is to look at all of the inputs and outputs of the current process.  This can include documents, data and communication associated with accomplishing tasks in a process. 

Next, we will want to evaluate the identified process to determine what manual steps in the process can be automated.  From identifying the steps we then can determine which ones will provide the best return for the business and/or user.

The last key to identifying and evaluating business processes is the inclusion of the user community in the analysis of the current process to determine; 1) what is currently working well, 2) what could use improving, 3) what are the major deficiencies and 4) what is on the user’s wish list for the process.

By following these steps in identifying and evaluating a business process you will set yourself up for success when architecting and implementing a solution for automation or optimization.

Implementation Strategies

Now that we have discussed identifying business processes let’s take a look at some implementation strategies to assist you in automating/optimizing the process.

  • Understand the Business Process: As discussed earlier in the post, it is critical to fully understand the process that you are automating.
    • Evaluate current bottlenecks
    • Determine the user interaction with the current process
  • Require Ownership at All Levels: In order to get full acceptance of the solution you are implementing you should ensure that the entire team is on board and understands the benefits to them and the organization.  This includes:
    • Executive Level
    • Departmental Management
    • End Users
  • Know what to Automate: Don’t automate every manual process for the sake of automation.  Determine the return value associated with the re-engineering of the process.  In some cases it will make more sense to keep the process manual.  For example, in a customer service organization, it may be more beneficial to provide human interaction to a customer instead of sending an automatically generated email.
  • Educate Yourself on Existing Systems: Understanding the current infrastructure in place can be critical when determining the return on investment and initial cost of the process re-engineering. 
    • If there is already an Enterprise Content Management system in place, you should be able to leverage this for tasks associated with document capture, document management/archival, workflow, etc…
    • Line of Business systems (Oracle E-Business, JD Edwards, PeopleSoft, MSFT Great Plains, etc…) can be leveraged for storing metadata associated with the documents you are capturing.   Using software like ILINX Integrate, these LOB systems can then be image enabled to retrieve documents directly from your document management system without ever leaving the LOB system.
  • Promote Ongoing Analysis & Optimization: This strategy is key to creating and maintaining truly efficient and optimized processes within an organization.  Let’s take the following example:
    • A manual process is identified to automate
    • The process is automated with success using the above implementation strategies
    • Everyone is happy and uses the new and improved process
    • Now that the process has been improved it is common to call the project a success and never look back.  This may work for some time, but eventually the process will need to be evaluated again to determine if additional automation or optimization needs to take place.  Over time business processes evolve and technology changes, so this step can be imperative to keep your business process streamlined.

 In summary, we have taken a quick look at the process of identifying business process to automate and optimize, as well as, some strategies for success when taking on the task of business process re-engineering.  Please feel free to post comments related to this information or your own experiences related to this topic. 

Ryan S. Keller
Project Manager
ImageSource, Inc.
  

You’re thinking about implementing a Content Management and/or a Document Management system.  What should I consider before proceeding?

  • You have lots of paper documents, micro fiche or other physical inventory that you want converted to electronic format.
  • You want to “Go Green” starting today.  You need the means to scan physical documents as well as import documents that are already electronic format (PDF, Tiff, Word, Excel, etc.).
  • You want to automate paper processes (Electronic Workflow) to eliminate the use of paper.
  • You’ll need software and hardware.
  • You’ll need some space in the server room.
  • You’ll need a project manager.

Hah!! (Light Bulb turning on in your brain) I have answered the essential questions, let’s go research and find a system that suits our needs. Better yet, let’s hire a Content Management and/or a Document Management consultant to help us.

Obligatory Disclaimer: I would not blog on this subject if I hadn’t witnessed, time and time again, a new process or environment installed that was left for personnel to administer without training and without a test environment (sandbox if you will) to learn and grow with. 

DON’T overlook the added value of TRAINING and a Test Environment. They are essential pieces to consider when deploying any system.

Think about it for a moment- When you first learned to tie your shoes, someone showed you the method of tying an overhand knot and then tying two bunny ears together. TRAINING!!  Then you were shown a few more times. Secondary or follow-up training!  Finally, you were left alone with your shoes and strings (your test environment) until after about 200 attempts, SUCCESS!!  You became an expert in shoe tying, a major accomplishment that we have all achieved.

The same can be said for many other basic life skills, like riding a bike.  You started off with three wheels, a tricycle or a big wheel.  Then you got your first bike, TRAINING wheels included.  You rode all over town, to your hearts content.  Then the big day came when the TRAINING wheels came off.  Mom and Dad ran up and down the street, hunched over holding the back of your bike seat while you struggled to figure out how to balance on just two wheels.  Mom and Dad nursed their aching backs willingly because they knew that they were helping you learn a new skill.

Why do so many overlook the added value of providing these same indispensable tools, TRAINING and Test Environments, for a Content Management system or Document Management system (or any system for that matter) that is worth much more than an old pair of shoes or a kid’s bike?

I speak for System Engineers and Administrators all over this nation: Please provide the necessary tools to support the ones that support your systems, the company, the bottom line, the knowledgeable professionals working diligently in their offices and cubicles, etc.  Set them up for SUCCESS at the beginning and there will less likely be failure in the future.

Related blogs on Software Development Training:

http://softwaredevelopmentforecm.wordpress.com/2009/09/25/ecm-best-practices-training/ 

Robert Gartner
Sr. Systems Engineer
ImageSource, Inc.

Share on LinkedIn   Share on Twitter

The term “Data Strategy” and can be used to understand strategic requirements for enterprise metadata concepts and best practices.  Why is this important for an ECM solution?  The simple answer is why contribute to the disarray of an organizations data management when implementing an ECM solution.

The key to a successful ECM system is the ability for users to easily and quickly find information within the repository.  If specific information cannot be easily and quickly found, users may not be enthusiastic about using the system.

The biggest stumbling block in the way of finding specific or relevant information is when the search returns too many documents that the user will have to physically look through before finding the specific document or set of documents that exactly meet their requirements.

In order to prevent this impedance to effective document retrieval, organizations have to be able to refine the population of documents that are searched so that irrelevant information is not selected and returned in the query result set.

In a well designed ECM system, this is accomplished by using metadata (or taxonomy’s) to limit the search result set to items which meet  the user’s selected parameters (i.e. date range, case number, document type, etc.).  Metadata is used to describe content that the ECM system intakes.

Metadata not only provides a way to index (and therefore retrieve) content but also it provides the means of managing content throughout its lifecycle.  For a document or item of content, this means data about it such as its author, its title, the issue date, and other information which can usefully be associated with it.

Whether you are using ILINX Capture, Kofax Ascent Capture, or Captovation users will have to enter some metadata, though as much as possible should be created and collected automatically if possible given the document sources, types, and available databases linked to documents.  It is important to get the balance right, too few mandatory elements may result in little metadata being entered, too many mandatory elements may be seen as a tedious chore.

Consistency and accuracy of metadata values is crucial to the value of metadata.  Controlled vocabularies, pick lists, default values and inheritance are all important tools and techniques in this context.

When designing a system the recommendation is to apply metadata to all documents that are expected to be found easily in a query and all documents that are stored as “final” archived records in the ECM repository.  This process will be essential in the user adoption and success of the system.  For more information please visit the North West’s premier conference at http://nexusecm.com and register for one of the ECM break out sessions.

Jon Sutherland
Sr. Systems Engineer

ImageSource, Inc.

mctsrgb_5302

 

 

 

Share on LinkedIn   Share on Twitter

There are a number of variables to consider before determining the document capture best practices for an organization. The first question I would ask is: Is this a departmental/workgroup or enterprise scanning solution? The second question I would ask is:  Is this an intelligent capture solution? The definition of ‘intelligent capture’ I use is: the ability to automatically separate and extract data from documents. Those variables should always be in the forefront of your mind when designing the capture solution. Setting those variables aside, let’s think about why we are even scanning in the first place. The goal of any capture solution should be to save money, where that money is saved varies from organization to organization but the goal is the same. Scanning documents has a cost inherently associated with it; the goal of any solution design should be to walk that line between the cost associated with input and the savings associated with retrieval/Business Process and come up on the winning side. There are many things that could be considered a blanket ‘best practice’ techniques for document capture but I believe the end goal (where you see the savings) determines the priority of those best practices.  

For any scanning solution, we have to make it easy. We need the application to be easy to install, we need training of end users to be simple; we basically need that ‘big red scan button’.  Certain software suites are more conducive to meeting some of these goals. Kofax Capture for example has a ‘big blue scanning button’, it is also quite easy for end-users. However Kofax Capture has a very cumbersome installation that can be difficult to deploy. Another product I deal with is ILINX Capture . ILINX Capture has a straightforward interface that is easy to train end users on. ILINX capture is a web based solution so deployment is far simpler than a standard client/server application. Determining which product is right for the needs of the scanning solution can be the first hurdle to cross over in the creation of a capture system.

Along the same lines of ‘ease of use’ is the idea of the metadata schema. For any ECM system the old adage ‘garbage in, garbage out’ applies. When capturing documents, it is best to make the association of the metadata (often referred to as indexes) to the image as simple as possible. Things such as pick-lists, database lookups, and programmatically enforcing business rules come in to play here. The goal in capturing the metadata is to make the documents easy to retrieve down the line so anything that can be done to enforce quality data can be beneficial. The goal of cost savings must be thought of here as well because the time associated with ‘indexing’ a document is a system cost that must be mitigated as best as possible.

When dealing with intelligent capture solutions image quality is of further importance. In standard archival scanning a 200 DPI image should suffice; when trying to extract data and separate documents automatically, 300 DPI or higher should be used. Think of it like this: just because you can read it, doesn’t mean a computer can. The more data an OCR engine has to work with the better the results. With an increase in DPI there is a slowdown in the capture process: scanners run slower, images process slower, required storage space on the back end increases. These are all things to consider.

In the end any ECM solution should save money and increase efficiency. Spending a little extra time when designing the capture portion with all the project goals in mind should pay dividends. A few of the things to keep in mind are:

  • Ease of use
  • Quality of metadata
  • Quality of image

Many of the breakout sessions at the Nexus ‘09 will touch on these points and many more. In Michelle Semple’s break out session she will discuss the value of in-process capture and the benefits of a web-based capture solution like ILINX Capture. In Sophia Marchi’s break out session she will discuss production scanning, some of the pain points involved, and how to maximize productivity. There are many more sessions at Nexus ‘09 that will touch on document capture and how to effectively implement or improve existing systems.

John Linehan
ImageSource, Inc.

Share on Twitter

With scanning software it is tempting to get carried away and create many different batch class configurations designed to be optimized for specific types of documents. The most common is when you see a batch class created for single page documents and another which uses exactly the same indexes and feeds the same application for multiple page documents. Often times the extra time spent separating the documents out into these multiple piles for input to the different batch classes offsets the time saved by the batch class optimization. In organizations which enact this you often find that the single page batch class has been abandoned as the workers tasked with document preparation, scanning and indexing come to the same conclusion. This is not an absolute but in general unless there are a large number of single page documents the extra batch class is not worth the effort. The follow up to this is when you do have one of these abandoned batch classes it should be deleted. It makes for less confusion for new employees being trained for scanning operations, and does away with wasted time spent on the non used batch classes being upgraded and tested during system upgrades.

Jeff Doyle
Senior Systems Engineer
ImageSource, Inc.