"What if the business is apprehensive to re-engineer the current system? Are there other opportunities for pursuing a re-engineering initiative?"
This is how my conversation with the Development Area Manager started today.
From the initial discussion we had on re-engineering a few weeks back, he went to our business partners and pitch the idea to them. The initial reaction we received was a bit lukewarm. Without the support of the business partners, we are looking for other ways to push the re-engineering agenda.
Innovate how we operate.
Rather than focusing on the client system, we can use the same re-engineering principles on how we work. The approaches used in systems re-engineering can be applied in innovations for application delivery and maintenance.
To do this, we will need to review the processes involved in application development and maintenance. By revisiting each phase on the software development life cycle, we identify the tasks we can re-engineer. To help us in our analysis, I have identified the following categories that we can focus on.
Recurring, repetitive and manual intensive tasks. From experience, most proposals will fall in this category. Not only are these are easy to identify, most developers will be drowning you with proposals as these are tasks we hate doing. It is good to work on these category first (especially since we are just starting to build the skills of our team) as the re-engineering activities required are simpler.
The re-engineering approach for these type of tasks requires a combination of standardisation and automation. First we need to establish the series of steps required to accomplish the task. From these steps we can determine which of them (if not all) we can automate through mainframe facilities like ISPF Edit Macros and ISPF Services.
Tasks with wait times or requires monitoring. Monitoring activities (like those by Production Support staff) are essential to ensure that exceptions are addressed promptly. Although important, the time spent waiting are opportunities better spent on activities that adds more value. With this, it is important that we find other ways of monitoring aside from
having somebody continuously looking at a computer screen until an event happens.
For monitoring non-critical activities, we can avoid manually monitoring them through the use of automated notification - the simplest of which is the email notification through the SMTP (Simple Mail Transfer Protocol) service. We can consider modifying a non-critical job to send the error details to the appropriate group if exceptions are encountered.
SMTP can also be used for automated report distribution. Rather than have someone kick off a process to create and email a report, we can replace this with a mainframe job to be triggered when the input file is created to process the file for us.
Tasks where human decisions are made. I am not suggesting that we replace all of the intelligent decision making activities with an automated process as this is not possible. In situations where the decision making is complex, we can help the decision maker by ensuring that all the information he needs are easily accessible. The benefit with this is that we don't change the way people work, we just eliminate the administrative part and let them focus on the parts of their job that adds value.
Tasks requiring system downtime. The activities that fall in this category overlaps with the other previous categories. We need to further categorised them into this type because of their impact to the business. System downtime (whether the downtime is for software migration or data/error recovery during production support) means there are no business activities in our system. Business opportunities are lost on periods when our system is inaccessible. With this, we must give special attention to activities falling in this category.
Pushing re-engineering forward.
There is a good incentive to devote the time it takes to re-engineer our development processes. If done right, these re-engineering successes will be the best marketing tool in selling the re-engineering agenda to our business partners. The tangible results are more powerful than any PowerPoint presentation we can muster. This will open up a wider horizon of opportunities for us in the future.
This is how my conversation with the Development Area Manager started today.
From the initial discussion we had on re-engineering a few weeks back, he went to our business partners and pitch the idea to them. The initial reaction we received was a bit lukewarm. Without the support of the business partners, we are looking for other ways to push the re-engineering agenda.
Innovate how we operate.
Rather than focusing on the client system, we can use the same re-engineering principles on how we work. The approaches used in systems re-engineering can be applied in innovations for application delivery and maintenance.
To do this, we will need to review the processes involved in application development and maintenance. By revisiting each phase on the software development life cycle, we identify the tasks we can re-engineer. To help us in our analysis, I have identified the following categories that we can focus on.
Recurring, repetitive and manual intensive tasks. From experience, most proposals will fall in this category. Not only are these are easy to identify, most developers will be drowning you with proposals as these are tasks we hate doing. It is good to work on these category first (especially since we are just starting to build the skills of our team) as the re-engineering activities required are simpler.
The re-engineering approach for these type of tasks requires a combination of standardisation and automation. First we need to establish the series of steps required to accomplish the task. From these steps we can determine which of them (if not all) we can automate through mainframe facilities like ISPF Edit Macros and ISPF Services.
Tasks with wait times or requires monitoring. Monitoring activities (like those by Production Support staff) are essential to ensure that exceptions are addressed promptly. Although important, the time spent waiting are opportunities better spent on activities that adds more value. With this, it is important that we find other ways of monitoring aside from
having somebody continuously looking at a computer screen until an event happens.
For monitoring non-critical activities, we can avoid manually monitoring them through the use of automated notification - the simplest of which is the email notification through the SMTP (Simple Mail Transfer Protocol) service. We can consider modifying a non-critical job to send the error details to the appropriate group if exceptions are encountered.
SMTP can also be used for automated report distribution. Rather than have someone kick off a process to create and email a report, we can replace this with a mainframe job to be triggered when the input file is created to process the file for us.
Tasks where human decisions are made. I am not suggesting that we replace all of the intelligent decision making activities with an automated process as this is not possible. In situations where the decision making is complex, we can help the decision maker by ensuring that all the information he needs are easily accessible. The benefit with this is that we don't change the way people work, we just eliminate the administrative part and let them focus on the parts of their job that adds value.
Tasks requiring system downtime. The activities that fall in this category overlaps with the other previous categories. We need to further categorised them into this type because of their impact to the business. System downtime (whether the downtime is for software migration or data/error recovery during production support) means there are no business activities in our system. Business opportunities are lost on periods when our system is inaccessible. With this, we must give special attention to activities falling in this category.
Pushing re-engineering forward.
There is a good incentive to devote the time it takes to re-engineer our development processes. If done right, these re-engineering successes will be the best marketing tool in selling the re-engineering agenda to our business partners. The tangible results are more powerful than any PowerPoint presentation we can muster. This will open up a wider horizon of opportunities for us in the future.
Posts
0 comments:
Post a Comment