accountant's role in IT implementation

I would have to say that I have never run across an accountant that had anything to do with IT implementation other than implementing tools needed for their immediate job roles.

1)To what extent have you encountered accountants involvement in IT implementation?
a.I could see Accountants installing their own tools on a Server to use for their job roles.
b.I could see an accountant team taking care of any permission or access rights into the tools that hold the information used by accountants in their job role.

2)Do we need them to be in the implementation team? why and why not?
a.I would have to say no in ?most? cases. Accountants choose, or are tossed, into their field to take care of business related to accounting.
b.Naturallyyou could have a mall group that can handle multiple ?hats?.

3)If they do involve, why do you think they involve? e.g. top management instruction.
a.I could see an accountant getting involved in the IT implementation because project management did not consider what an accountant is really used for.
b.I could see an accountant doing the implementation because they are cross-trainning to a technical role in the company.

4)Do they have the skills required to be part of the implementation team?
a.This would depend on the individual. It is no unheard of to handle multiple jobs at once.
b.If you break down what one would learn trying to earn an accounting degree vs. a technical degree the topics of discussion are much different.

Hope it help. Good Luck!
-Jim

1) I was upgrading our payroll server and needed their input since it was an application they used everyday. Mainly the input regarded, what security to set, and where to house the server. Plus a few other things.

I also had to involve the finance dept, on any new purchases because only they knew if we had the money or not in hard times. It had to be a seriously important item to get any spending over a few hundred bucks.

2) if its relevant to them, they should be involved.

3) They are involved to either keep costs down, or get their needs met depending on the situation.

4) Yes, in certain circumstances they do have the skills.

If you are using ?implementation? to cover the whole project process, then accountants have key inputs into the process. They should be involved with the business objective phase since businesses exist to make money and even non-profit and government organizations have to live within a budget.

Accounting should be involved in establishing the business requirements. In particular, the tracking of assets and costs involved with any IT project. This can save IT teams hours of work later doing inventories and confirming installation dates. The accountant brings valuable input into such issues as how an IT element is tracked as an asset ? by system or by component. There are taxes and general accounting principals involved that most IT professionals fail to understand. Accounting practices can also provide valuable input to the operational aspects such as properly tracking warranty and maintenance agreement information to minimize costs.

By including the accountant input in the business requirement phase, the technical objectives and technical design can include the proper linkage back to the accounting system. This is has a cost and value element in the overall project. There are soft dollar costs associated with reconciling the accounting system to the inventory. These are reduced or eliminated by a little effort up front.

Accountants may assist the project manager with tracking the initial project costs, and with identifying the actual return on investment over the system life cycle. Such assistance can make the difference when the next initiative is being considered.

Why would you use an accountant or business resource on a project? I will use the term business resource because sometimes the application is not accounting related it can be an operations application.

The main reason to have business resources on a project would be to ensure that what you are developing actually meets the business objectives. This would all hinge on the complexity of what you are trying to do. The current project I am on has almost a 50/50 split between IT and Business resources. This is necessary due to the overwhelming complexity of what we are trying to do. The business folks define the business requirements and then assist the IT staff in the technical design. The business folks decide what needs to be done and the IT folks decide the how.

In some cases the IT resources know the business as good or better than the accountants. With my experience I have found this to be rare. History has proven that we often draw up some requirements documentation at the beginning of the project, hand it off to the IT department and they go off and develop it. Months later they comeback and tell the customer it is ready to test and everyone finds out that somewhere along the way an incorrect assumption (or three) was made.

With imbedded business resource you can validate and fine-tune the business requirements through out the project. It is also critical that the business resource actually know the business in detail. You would never assign a web resource to a DBA task. Likewise you need the right business knowledge. It also goes a long way if they understand the technology, however some of this can be learned along the way.

In the end it is important not to focus on what the technology can do, but what the business needs to do. In my opinion having business resources helps to shift the focus back onto what the business needs to do.

-PNC

I had to collect offers and then implement an accounting system chosen by an accountant. Unfortunatelly, the choise was cheaper and based on the explanations/promises of the offerrer's Marketing Manager.
I still believe that IT stuff's oppinion should be considered much more carefully. In fact, the proper professional to give the most heavy oppinion should be a System Analyst.
The accountants took place in the implementation as providers of the initial data and in any aspect concerning theirparticular roles /they had a lot of decisions to make since the system turned to be much more "abstract" than we expected/. Of course, this caused some troubles visible after time because it's not accountant's duty to know how - for example - the wrong coding system may make some ranges of data uncoverable in one and the same report and it was not our duty to know accounting, so we could presume all needed reports /but a System Analyst should have some good knowledge of both/.
In general, accountant's role in IT implementation depends on what do You implement and - very important - how Your Boss imagines the implementation process ;)

I am curious as to what changes in the process might have helped a better solution. Do you see any missed opportunities in retrospect?

Your "...list of available sollutions of the kind "ERP"." jumps out at me as maybe the business requirements were not as well defined as they could have been. However, I wasn't there so that may not be the case.

I like to see an org chart type approach that links from business objective all the way down to the physical, logical, and component design, butthis can be hard to do.

1 and 2) First, depending on the size and scope of the implementation, I always have an accountant on the team for job costing and budget control. Second, if the IT implementation affects anything to do with accounting/financial processes it is bestto have them on board. If the IT implementation affects the legal department then I have an attorney on the team; shop floor control? then have a production guy handy. Get the drift?

3)They get involved to make sure business objectives for the implementation are being met.

4) They sure do. I believe you are looking at an IT implementation strictly through the eyes of a technician or installer. For a company-wide implementation you better have company-wide representation.

Unless you are dealing with specialized applications that don't touch on money, account structures or other fiscal tracking functions, you'll likely need an accountant. And if a project meeting the above criteria is big enough, you'll still need anaccountant, if only to help keep the costs under control.

Said accountant should be intimately familiar with the organization's account structure because that often needs to be considered when setting up essential controls or tracking project costs. The accountant should also be familiar with timing issues relative to various accounting processes. It can be quite stressful implementing a new system while doing year end close. And there are times when delaying or accelerating a purchase can make a big difference in an organization's monthly/quarterly profit/loss statement.

The first think I think you want to do is make sure you're separating "Accounting" from "Finance". Having been in the latter field, it's easy to see the major differences between the two in terms of skills and abilities. It's the effective equivalent of calling a systems administrator a help desk tech.

With that being said, I would be hard pressed to see the value of an accountant in terms of IT. Typically your accounting roles are the ones that understand the "nitty gritty" of financial endeavors, such as taxes, depreciation schedules, and the like. Unless they are a user, there's probably very little in the IT world that accounting would have their hands in.

Finance, on the other hand, is probably involved in everything (or at least should be aware of it). Your Finance team typically looks more at the "big picture" in terms of forecasting, busines case analysis, opportunity costs, etc. They would be the ones running the different scenarios ("what if development takes three times as long...", "at what point do our benefits surpass our investment...", etc.) and ultimately would be the ones who would need to buy-off on any IT project.

Having been both in IT and in Finance, I can truly see the value that the latterorganization adds. They are an independent source, so they can recommend the tough decisions without a bias that IT-alone cannot provide. For instance, if a project goes well over-budget, it may make financial sense to cut our losses and abandon the project. Finance can't make that decision in a vacuum (they need to seek input from the appropriate sources), but they can provide an objective view, and get away from the "but we've already sunk $2M into this project, we don't want to waste that" philosophy (which has been used to justify FAR TOO MANY projects).