Considerations for Architecture and Deployment of Global Capture Systems

 

The considerations for architecture and deployment of global capture systems are several fold. In our experience they include the traditional considerations and methodologies (software deployment models, conventional server models, fault tolerance considerations, human resource considerations, change management, etc.), however, in the global context there is another set of considerations that must be factored into the decision making processes. Regardless of the quality or nature of the software, there are myriad factors (independent of the software application) within any global corporation that can and will affect how that software is implemented and how it performs in any given region of the world. The ability to implement quickly and efficiently is tied directly to the organization’s communication structure, reporting structure, internal politics, policies and procedures, physical infrastructure, and the relationships that exist between the various IT support groups and the business. Any distributed applications performance can be impacted by the network, security configurations, load balancing systems, WAN Acceleration systems, and all of the rest of the traffic traversing those global backbone and regional networks. Many of these factors can and often are completely beyond the control of the customer’s project teams, and those that do control them often have completely different reporting structures within the organization.

Having a clear handle on the state and configuration of the existing environment combined with well managed Command and Change Control structure and a central hierarchy of authority that can be used for escalations is vital to the ability of ground teams to implement, troubleshoot, correct, adjust, optimize and complete rollouts in a predictable, consistent and timely manner.

Most of these factors are never fully known or understood until the teams are well into the planning stage of a given project. There are several ways that any global rollout can be approached from our perspective. Our preference is to work closely with your teams to understand the traditional factors as well as the lesser known and intangible ones so that together, we can arrive at the most effective, efficient and reliable ways to implement for each given region of the world. In our experience we have also found that being flexible as a combined team in our approach can help to ensure successful outcomes at the end of the day. We have to plan based on the information available at the time. As new information becomes available, we work together as necessary to modify the plan to achieve our stated goals and objectives for the implementation and to satisfy the needs of the users. At the end of the day, from a users perspective, it just has to work.

Gene Eckhart

Program Manager

ImageSource, Inc.

  

What Type of Search is Right for You?

For many functions in the organization the full text “Google” like search capability found in most document management systems may be useful.  For others, it’s not sufficient in providing the business value.  Here’s some situations that may help determine what is right for you.

A business professor once said “There are three core functions to any process… 1. Procurement of Materials 2. Conversion of Materials and 3. Distribution of those Materials.  All other functions only support these three”.  In translation, these three things can map to any function found in business for any department (Sales, HR, Information Technology etc.)  It seems that when analyzing any business process, this old adage always comes back and discussing search in the enterprise is no exception.

When looking at search it’s helpful to see both sides of these functions for document management.  Documents either “drive the process” as a core function, or documents are ”driven by the process” as in a supporting role.  The differences are not all that hard to see.  Document that drive the process are directly related to the three functions above 1. Procurement 2. Conversion and 3. Distribution.  Documents that are driven by the process may be everything else.

Vouchers, Invoices and Checks are all documents that drive Purchasing.  Service Orders and Proof of Delivery are documents that drive Operations.  Purchase Orders and Service Contracts drive sales. 

On the other side, Marketing Literature  is driven by Marketing.  Brochures are driven by Sales.  The company Calendar is driven by HR and Inventory Reports are driven by Operations.  These documents support the functions of their departments.

A less technical way to look at this dichotomy is ”gotta have that document now” and “gee, this looks like what I’m looking for”.  When designing a search architecture, this is one of the basic questions you can ask yourself.

Documents that drive the business process tend to require a discrete index field search.  This is because the user is typically looking for the one document they need, and they need it quick.  A Sales Order for a customer service representative or an Invoice for a purchasing manager.  These documents also typically already have a structured meta-data component already designed for them before the document management system is in place.  A Sales Order Number field is always generated for Sales Orders and an Invoice Number Field always has an Invoice number.  This is true before or after a document management system exists.

Documents that are driven by the process are less structured in nature.  Marketing Literature, Progress Reports and the Employee Vacation schedule to name a few.  The user is typically looking for some information that could be in one, or many of these documents.  Could an employee figure out if Memorial Day is a company holiday by finding the wrong documents to their search?  Like last years vacation schedule?  Probably so.  If this is the case, a full text content search may prove successful.

Documents that “drive the process” answer questions to a search that only that one document can satisfy.  What items were billed for Invoice # 123456?  What date was Employee #78910 hired?  Who signed for Proof of Delivery #34567?  In these cases, a discrete index field search is required.

 

John Moffitt

Systems Engineer

ImageSource, Inc.

http://www.nexusecm.com/index.htm

www.imagesourceinc.com

www.ilinxcapture.com 

  

The Two Faces of Change Management

Enterprise Content Management implementation projects frequently require the formation of plans for, and execution of “Change Management” as a major part of the project components.  But what is Change Management?  In ECM Projects, participants have been known to describe Change Management using two very different definitions:

[1]  “Change Management (People)”- ECM projects sometimes include significant business process changes that require the user community to change the way they work.  This is especially true of solutions that involve transactional processes.  Process change situations can challenge the success of the project if the users are not involved and informed.  If major business process are major or widespread, the support of executive and middle management is crucial and needs to be effectively communicated to those users involved with the changes.

[2]  “Change Management (ITSM)”- Most ECM Projects, no matter how well planned and documented, will usually have situations arise where plan details should change.  Changes to the plan can be requested by the implementation team, the project sponsor, or a key organizational department.  The Project Manager(s) responsible for the success of the project must have a formal process to receive Change Requests, process, and then respond to them in light of their impact on the design, cost, and schedule of the project.

Neil W. Lindsey
ImageSource, Inc.