Overview

Agencies have diverse needs. Not only are agencies chartered to serve various specific populations, they serve those populations with a wide range of services. Organizational structures and methods of work vary greatly between agencies. An enterprise operation system, such as AIM, must therefore demonstrate a commensurate level of flexibility not only in how it uses technology to support specific methods of work but also in how those technologies are introduced into the enterprise delivery process. As a system becomes larger and more comprehensive, the need increases to provide a discrete, manageable framework of implementation segments. The AIM system provides this discretion and flexibility at the very core level of system design.

Virtually any section of the AIM system can be turned on or off, made view-only or editable; and even the vernacular or referential nomenclature with which system functions, content, and data-points are labeled is easily alterable. This approach provides an unprecedented level of adaptability to a particular organizational approach. This level of choice can, in fact, be created for each individual user in the system. Because of this, the AIM system avoids the potential for the induction of uncertainty or even chaos in the implementation process. The implementation points can be surgically selected and deployed, and the time-line and staffing impacts for the rollout of specific functionalities can be tightly controlled.

The Implementation Cog

If system implementation is conceptualized as the creation of a set of interconnecting cogs, as in a clockwork, with an overall purpose of moving and organizing data throughout the enterprise; the various functional tasks could be thought of as “implementation cogs”. A particular functionality or “cog” could be selected and, within a set of basic conditions or prerequisites could be introduced into the overall enterprise data structure as a more or less independent capacity. Many such islands of functionality will begin to play interdependent roles with other point solutions and staffing capacities. In this manner, complex systems can be built up, over time, of a number of easily managed and implemented core capacities. Incident reports, for example, or medication errors, or progress notes could be individually instantiated enroute to a fully functional set of Treatment Plans within the system rollout schedule.

Implementation Composites

Each of these implementation points, or “cogs”, while addressing specific functional requirements, will share a certain commonality with every other implementation point in the system. Each time the implementation process is repeated, there will develop a growing competency on the part of staff and project management team that will facilitate an easing in learning curve and an increasing predictability in the overall implantation process. These common implementation composites, or “spokes” to continue the analogy, will create a reproducible approach to the overall project.

If the basic demographics capacity of the software, for example, where envisioned as one of these “implementation cogs”, the various spokes might be:

1. Data Collection
2. Data Conversion
3. Staff Requirements
4. Technology Access
5. Process Management
6. Operational Disciplines
7. Staff Training
8. Reporting Requirements

The content selection for each of these “spokes” in this implementation process might be envisioned as follows:

Another advantage of this approach is that discrete functions can become operational independently, each one contributing an incremental benefit to the overall system value proposition and thereby substantiate an on-going quality improvement process in the total implementation effort.

Implementation Segments

Although the following is by no means exhaustive, a sample of potential implementation cogs are summarized as follows: