When I initially started at the mine around 3 months ago I never anticipated that this industry would have as many acronyms as the IT industry. I was wrong. My first technical conversation with one of the electrical engineers here (and while learning something fascinating about transformers and how grid type energy is distributed down to a substation level) I realized that there was a lot in the conversation that had passed me by. I hadn't as yet learnt enough to appreciate the subtleties of electronic notation. It took me a good few hours of pouring through papers of schematics and Google searches to finally find the unique identifier for the transformer I was looking for. I had a similar experience when trying to find the identifier (and relevant schematics) for a light in a fridge that was broken in one of the water wastage plants. What is very clear here is that not only do they have a different business language, but each profession here has their own language with its own structure, notation and semantics.
How this plays out in a meeting is very interesting to say the least. I have been to several thus far and I can say this, when the conversation is around production, all the respective professions seem to gel and come together, however with IT the fit seems almost awkward. I attended an inter-department meeting last week that was called to discuss a big change was being made to the maintenance system. The formal agenda described walking through the change that will be made, the when of the change and a discussion around what to do when the system comes back online. You see, they needed to alter an underlying relationship between certain selections (please excuse the vagueness, but I can't offer more specific detail) which relate to applying a different cost model to maintenance changes that affect all the main business units.
While I was listening something struck me as one of the senior IT staff spoke about the changes they will be making and the responses (or rather lack of) from the other business units. If I closed my eyes, I could have easily imagined myself to be in a software development meeting talking about database changes. The dialogue was very IT orientated, and this was further emphasized by the heading of the agenda being the SQL Change. The changes were described in data schema terms. There was nothing in the conversation about business impact and mitigation strategies to handle the system being taken down and loss of immediate data entry. Additionally, the business units were somewhat quiet in the meeting…
Another thing that caught my attention was the diagram on the board. It was a mix between object UML notation and a flow diagram to display the relationship between three objects. It isn't something I would have expected in a focused meeting to deal with system change where there are business users present. I was also puzzled that none of the changes spoken about where actually shown on the projector. They showed a list of this is what is going to be added out of an excel spreadsheet, but it would have been really good to see an actual "this is what it is going to look like" example.
Taking that further, what made me worry somewhat was the lack of coverage over what happens to the business when the system is taken down. In essence they were told to fend for themselves and use whatever manual method to capture their data while the system is offline and when the system is back online, they would need to enter all the data manually. Unexpected.
A big part of me wanted to say with a puzzled expression "Surely you are not serious?” My confusion arises out of the knowledge that it isn’t difficult to setup an excel spreadsheet template and then write a script to import the values straight through the interface (you can do this so easily with Ruby and Watir). I say through the user interface because then you don't contradict any underlying business logic that is applied as the data floats down from the user interface layer through the code and finally lands in the database. Also, you don't end up having problems with auto generated keys and so forth. Also, should you need to take the system down again, the script and template serves as a backup and can be run locally on a users machine. It isn’t the only solution (I would love to hear what others have done in a similar situation, if you do have an example please mention it in the comments) but it does represent a bit of investment for potential medium to long term savings.
Overall, the team seemed unprepared. I do believe that the intent is there to provide a good service to the business, but there are short falls in their approach. I am not sure of the reasons why, but there was a definitive lack in quality in the message they presented. It seemed awkward and out of place. As a technical person the meeting wouldn’t have bothered me in the least, but as a pretender user it did leave its mark. It seems that IT lacks a "production focused business language" equivalent that would convey the necessary intent to the other business units. Which brings me to three questions I want to ask:
· Do distinct technical terms and language (even words such as SQL) belong in a business meeting or should IT take on a more business focused language to convey system impact?
· Which diagrams/models/images do you use to explain your changes and potential business impact to business users?
· What has your success been like with the approach you chose to address the above and do you see a relationship between the types of users or business and the end result?