Over the course of our years working with Control-M, after having worked with the various teams that maintain and operate the solution in their respective places of work, one thing remains the same: the human element. People love process. Why shouldn't they? Process makes life easier, following it typically provides standardized results, and processes can also be passed along, as roles and positions change.
What happens when you throw existing process into upheaval? Adjusting takes time. People have a tendency to resist change that isn't brought about with proper structure. Having to consider all possibilities can lead to analysis paralysis. How do you achieve buy-in from the multiple teams that rely on Control-M for your daily processing, while still moving your project forward?
Achieving buy-in from multiple teams can be time-consuming, and discovery is critical. It is guaranteed that bits of human process will come creeping out of the woodwork, and will require further solution design or additions to your existing migration or conversion plan.
There is no way that your team can integrate changes to your scheduling environment without hosting many meetings, gathering information from all of your involved teams, before moving forward. Likewise, you must communicate all that has been discussed, document proposed changes, and draft a mapping document outlining what old notions have been replaced by newer ones.
In addition to this, why is simply converting the baseline hazardous? Why would you, as the project manager for this Control-M conversion, want to preserve how the workers worked before, when the underlying product has changed? It's important to understand that when converting, people are going to search for equivalencies, and will want to continue on with their old processes. In some cases this is alright, in many others things will have to be adjusted.
Existing hard-coded software solutions that have human processes that revolve around them also come into play here. Custom developed code that requires human intervention might not always immediately be properly taken advantage of by Control-M. When tertiary bits of software responsible for timing and triggering enter the picture, how do you mitigate people's desire to continue to use them as before?
All in all, here are some things to look out for when considering human process in a Control-M Migration or Conversion:
- What teams need to be brought on board?
- What items need to be communicated clearly?
- What will be different, what processes will need to be adjusted, and how?
- What will the steps be in migrating or converting, and when will they happen?
- Who will be part of what activities, and why their roles are crucial?
May your conversion efforts go smoothly! For any of your Control-M needs, drop us a line, it's what we do!
The CFS Team