Software Consultant For Hire

The project is the mapping of a proprietary end-to-end enterprise resource planning platform (ERP). The CIO described a sort of subway map design that would enable any user to locate a process – like a colored tube – and then see all dependent processes, resultant processes, and points of intersection or change.

The idea is brilliant. I mentioned it once before, with some over-indulgent transcendentalism chatter. At the time I was just thinking casually about it. But a month ago I actually volunteered to do the project. They did not hire me. That’s fine.

If I were going to do the job here’s how I would do it:

1. Outline the objectives
2. Create a scalable plan
3. Identify and define core processes
4. Categorize secondary processes
5. Code the elements

Begin with the end in mind

Objectives must be clearly defined and agreed upon as both reachable and beneficial to the business. In this case, the primary objectives are:

• create a universal reference via knowledge base
• identify gaps and inconsistencies for maintenance
• define operating standards to which all future developments can be compared.

I would then create a scalable plan.

Set Expectations

Something like mapping a complete end-to-end ERP could take years. So laying out the first phase and creating some boundaries that translate into progress and some others that represent phase two, phase three, etc. can help set expectations.

A preliminary scalable plan might be organized one of three ways:

• By Priority – let’s use neighborhoods to identify the various blocks and streets that may depend upon one another. A city model might work here as some elements of software are firm grids and others are winding half-streets or dead ends. Organizing by relationship allows the plan to scale based upon the focus of the construction efforts. For example, if the sales screens are receiving developer focus, then the mapping should work the sales screens first. Sales screens are revenue generators; they will receive the lion’s share of resources.
• By Relationship – how are the transactions in one neighborhood similar to those in another neighborhood? Organizing a plan by relationship allows the map to employ similarities to duplicate elements but also develops a natural compare and contrast analysis, useful for objective #3.
• By Accessibility – there is nothing wrong with approaching any project by completing the easy tasks first. So a plan built on accessibility would get the easy maps out of the way first. Those processes we full understand, that are wholly independent, or that are run by people in the same time zone could be tackled first.

Scalable plans have the unenviable task of suggesting how long the entire project will take. They should also include likely challenges, potential threats to completion, and alternate suggestions should the plan not be completed within the original scope.

Use Broad Strokes for Landscapes

The next step, after the plan is decided upon, is to identify and define core processes. The processes with which to begin are dictated by the plan. The mapping of those processes requires investigation, transcription, documentation, verification, and publication.

I would begin with interviews in the investigation phase. I would use transcription to identify the key elements of the interviews and to categorize the responses. Documentation would combine of all sources of information into a single process outline.

Once that outline is verified, the map should be drawn or published. This process is repeated for all of the core processes and should result in a skeletal model of the system.

Fill in Detail

Secondary processes will be discovered during the investigation of the core processes. A running list should be kept in preparation for the secondary process stage of development. After adding any additional known secondary processes which are not on the list, I would categorize the secondary processes.

Categories can enable duplication to be used when documenting and mapping. If, for example, one process has a similar trajectory, duplication will enable the map to maintain consistent vocabulary, style, and relevance.

Finally comes the coding of elements. On a subway map symbols indicate stations where riders can change trains and colors maintain train identity from point to point.

When mapping a software system using process trajectories as patterns and shared tables as intersections, we need symbols to show common behaviors. The data is retrieved in the same way, but used differently. Symbols work as categories and help identify similarities and differences between elements.

Why it matters

In all enterprises there are certain activities which receive laser focus. Countless hours of dedication and effort are applied to them in the hopes of ensuring success. These activities are usually the sexier, profitable activities, those more interesting to the actors or more immediately profitable.

Yet many processes suffer from poor initial construction and the enterprise can spend any number of hours patching and fixing instead of growing and developing. If it were up to me, I would apply at least a modicum of focus to the underpinnings so as to avoid wasting hours "fixing" one side of the structure while inadvertently weakening another side.

When they didn't hire me, they turned a job that needed doing into something that will never get done. But like I said, they didn’t ask me.

Take Action

Hire me? View my profile on LinkedIn here
Chat about such things as this? Connect on Google+ or see my Facebook page here
Find out when I'll post literary stuff (Monday) or Family stuff (Friday)? Subscribe to this blog by putting your email address in the box to the right.

Thanks for reading!