Every time I go to customer sites I look forward to learning new things. One of the things I always look at is how they structure their IT.
IT is something that almost every company these days have to deal with. But it is not their core business, it's a tool, a neccesity.
So for most companies the IT "department" is not integrated into the companies daily business. It can be compared to accounting in the "old" days.
Before we started to automate accounting someone had to do bookkeeping. It seems to be a forgotten craftsmanship but only a decade or two ago someone used stuff like calculators, pens, preprinted paper to calculate the profits and costs of a company. Today most of "our" customers don't have that. Their business processes "generate" the information to be used and analysed at runtime by managers.
When we look at how most companies run their core business it is either done using repetative processes or on project bases.
A repetative process is something that repeats in a standard timeframe and includes the same acts to be done over and over again. For example a shipper. Each day he/she need to see what needs to be shipped, pick the items and place them in a truck. The next day the same process is repeated. A machine worker may have a process that repeats every two hours or half a day depending on the product produced.
Someone might also have a multi day repetative process. A truckplanner for example The first day they collect the shipments that need to be shipped and the truckdriver leaves. On the second day the driver arrives at the customer and the planner needs to find return freight. When this is collected the truck returns home on the third day. Then the process starts again.
A company can also implement large projects. For example a construction company can build a house or a factrory. A furniture manufacturer can build a custom made sideboard or cabinet. These companies typicaly work from project to project. Some project can take longer to complete than others. It can also happen that people work on multiple projects. For example two days per week on project A and tree days on project B.
Some companies also work ad-hoc. They handle work as it comes in. Real estate companies or retailers. These companies don't know their work load up-front and try to manage whatever comes in.
The key in structuring IT departments is combining these three concepts into a working machine. The IT department needs to be able to deal with repetative work, longer projects and ad-hoc work.
This is difficult.
The larger your IT department get's the easier it is to organise this. If you have at least two people you can have one handle the ad-hoc and repetative processes while the other can handle projects without being interupted.
It gets more complex when the IT department is only one person, or part of one person.
Every IT department has repetative processes. Replace backuptapes, check interfaces & night jobs, run software updates, etcetera. But IT also has a lot of ad-hoc work. The printer does not work, a computer breaks down, creating a new user, you name it.
Most companies know by experience the average load of their ad-hoc work and try to combine this with their repetative processes.
The difficulty starts when trying to combine this with project work.
This is where it goes wrong
What types of project can an IT department have. For example, replace all printers, upgrade exchange, expand the citrix farm. These are examples of projects that need to be taken care of either one at a time or parallel. The projects are finished at one time.
This is where does Dynamics NAV comes in
When a company decides to purchase dynamics NAV, their IT department will first try to manage this as a project like implementing exchange. Something that is completed sometime.
This is both true and false.
What is the key to success
If you want your IT department to run efficiently their tasks should be definied carfully and with enough time to perform each task. Define the amount of time that each type of task requires and what type of task it is.
Repetative tasks should always be done, no matter how boring they are, no matter how many times the backup succeeds, you don't want to miss that single time it fails.
Schedule time for ad-hoc issues. The time needed for these tasks depend on the way you structure you repetative processes and internal procedures. If you never check your systems it takes more time to fix them when things go wrong.
Use the remaining time for projects and discuss progress periodically. If an ad-hoc task takes away project time then discuss this with your project manager. Some other process might be scheduled that waits for the IT department to be completed.
The complexity of the combination
Companies that are used to doing repetative processes or ad-hoc work are normaly not used to structuring a project. On the other hand, companies that are used to do projects might not understand the impact of adhoc work and time needed for repetative work.
A solid IT department, weather it is just one person or ten people has a good understanding of the complexity of these types of work.
The future of IT
It might sound strange but I think that, in the future, "Classic IT" will also be a forgotten craftsmanship just like classic accounting.
The reason for this is the cloud. And the cloud is moving fast.
Only 18 months ago I had to advice a customer on investing in hardware. We decided to purchase the "boxes" and place them in a hosting center. We used citrix, exchange and SQL to bring the information to their desktops.
Now if I had to advice them again today I would do it completely different. I would advice to host exchange and Dynamics NAV in the cloud. Use Skydrive for their documents and use any device they can buy on the market to work on. If the device breaks down, buy a new one.
Now this may not yet be applicable to every schenario but imagine the impact of this on inhouse IT. Just imagine.
As you might have read in one of my previous posts, I have lately done a turbo implementation with a large number of customisations.
As always with these kind of implementations it is not 100% issue-free when going into production, especially when implementing in such short time.
When we started to implement you make the usual list of things mandatory to have, things important to have, things nice to have and things cool to have but less important.
Now in a normal implementation you would focus on having at least the first three, or if not possible the first two before going live. We had to focus on only the things mandatory to have.
This makes sure that the system behaves as wanted if used correctly, but as most of us know, NAV's flexibility really becomes the heel of Achilles when people start using it, especially the classic client. By accidentally starting a wrong transaction by pushing a wrong button or setting up new masterdata wrong you can start an irreversable process. For example, if you create a new item with a wrong costing method it's next to impossible to undo.
So in the first few weeks after go-live the classic "Known Issues" list started to exist. Things that "Go-wrong-all-the-time" because people don't use the system how they should. Some of these things are easily fixed by people getting more experienced with the system, extra training or a small TESTFIELD or FIELDERROR somewhere.
Then what's left is the list of issues that take more time to fix. Normally no problem if you implement mandatory, important and nice things before going into production. So we had to make choices. Which issue to start working on.
In these situations you can never make a "right" choice. Whatever you decide, someone will be happy and everyone else will be dissapointed.
This is where project management get's really important. The classical phrase here is MANAGING EXPECTATIONS.
In our case we made the decision to implement some of the important issues that should have been done up front, knowing that we had some loose ends in the things that were running. And as you aldready know: What can go wrong, will go wrong.
Whenever this happens it is important not to end in discussions with end users or their managers saying "It's the system". Make sure to have a list of issues that you know that can go wrong and discuss them with your end users. This way you share responsibility.
Yesterday we had the first office meeting since "go-live" and the management asked me to join the meeting. Primairy reason: he was affraid for "it's the system" answers to everything that goes wrong. And they tried, as always, to blame the system.
But since we were prepared we could point at the shared responsibility. We explained why decisions were made to prioritise differently.
This is, was and always will be a difficult scenario in each customised implentation.
Transparancy and communication will prevent you from having an escalated project.
To be continued...