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.
Nothing new, all old thruths or ... opinions but you speak well, I give you that.