Developing a finance system

davetherave2 · 4 Nov 2009 at 13:17

Right long story short I am looking to create an internal finance system for an application that I have.

Currently the application uses a third party product and the data is pushed to the package from our application.

Due to our current system being a bit outdated and having so many patches/ remedial work done to it the decision has been taken to design and redevelop the system.

Foolishly i suggested that we should build a finance system into the new system thinking it would be relatively easy but after consulting our finance department I have found it is more work than I was expecting.

The reason for doing this is that we could do a lot more work with our system and then push the data to a third party product/ number of third party products.

So are there any good resources that anyone can reccommend that would do the job. I have found one website that seems to give me a little bit of info but not enough to give me a full understanding of what i need and why i need it.

Thanks in advance for any help.

~J~ · 4 Nov 2009 at 13:44

Christ!

Developed a few in my time and everyone is different and NEVER goes smoothly as new features are added all the time.

Couple of things to consider though which are often overlooked are:

Different account types (0001 - Supplier, 0002 - Contract, etc)
Accounts on hold
Post-dated payments, bulk payments
Ability to have VAT on a per customer basis (as an example, Eire customers aren't 15%)
Talking of which, ability to change VAT (VAT goes back to 17.5% in January 2010)
Account changes (a log of what people change is always a handy thing)
Access levels so that the temp can't access (or change) peoples DD information but supervisors can
Reports galore!! (again make a point of doing this at an early stage to validate your data)
Record locking is a MUST. You don't want user A changes details on the same record as user B (or if you do, have some way of tracking)
Account notes, keeping track of calls to the customer.

There's an endless list of things, some essential other aren't.

Nice meaty project you got there

davetherave2 · 4 Nov 2009 at 17:50

thanks for the info.

Many of the points that you offered are things that i have already discussed with the finance team/ or are things we currently have with our existing third party package.

But boy did I underestimate the amount of work involve you mention a systems upgrade to finance people and they want everything plus the kitchen sink adding into the new system

I really should have kept my mouth shut on this one. Oh well I know it is going to be painful to start off with but at least in the long run I know that we will have a more flexible system with greater control.

Deanje · 4 Nov 2009 at 18:48

~J~ said:
Christ!
Reports galore!! (again make a point of doing this at an early stage to validate your data)

Oh, and after all that, there's...

~J~ said:
Christ!
Reports galore!! (again make a point of doing this at an early stage to validate your data)

Good luck!

dangerstat · 4 Nov 2009 at 19:05

davetherave2 said:
thanks for the info.

Many of the points that you offered are things that i have already discussed with the finance team/ or are things we currently have with our existing third party package.

But boy did I underestimate the amount of work involve you mention a systems upgrade to finance people and they want everything plus the kitchen sink adding into the new system

I really should have kept my mouth shut on this one. Oh well I know it is going to be painful to start off with but at least in the long run I know that we will have a more flexible system with greater control.

Well you've done the right thing my talking with the finance team from the off. Really you want to know *EVERYTHING* they do at the moment, and *ALL* the issues they have with their current system.

As has been highlighted validation is key and also security, epsecially if this will handle paying peoples wages! Design clear and well documented OO code for something like this, make everything as easy to enchance / change / expand as possible. Don't hardcore any variable unless you have to (VAT was a good example as stated above - I've fallen pray of this in the past).

NickK · 4 Nov 2009 at 20:10

~J~ said:
Christ!

Nice meaty project you got there

My exact thoughts

Careful with tax - do the finance team currently use their package to submit tax information to the inland revenue? The reason I say this is because IR certify the applications that do this - if you replace it they may loose that. Remember if the company file incorrect financial reports to the government the repercussions could be severe.

In short you will not be viably able todo this by yourself. You will have also sold your soul to the devil for maintenance and report change requests.. with the added bonus of if there's a mistake your finance director will be having kittens..

What sort of resources do you require?

The main thing is to get a feel for the business requirements - this includes not only the use cases but the future financial strategies (ie what the finance dept want to do over the next 3 years). You're into the world of 'enterprise' if you're company is of any reasonable size thus you'll need something you can quickly add business logic to and whilst maintaining coherent data with all the constraints and protection (yes use a proper back end system!).

Don't forget migration and as it's mission critical - backup and recovery from disaster.

I sincerely hope you have a team doing this and that those concerned know the risks, costs and timescales going forward.

davetherave2 · 4 Nov 2009 at 22:53

well I work for an smb of around 100 - 200 people. As mentioned we currently use a third party system which was put in place 5+ years ago and has never had any real updates from the vendor who supplied it to us.

We have recently had massive issues with the data not being stored correctly so have had to get them to fix the issues which is still an on going thing 1 month later.

The intention is that we have a two tier finance system. We have the finance system which is internal to our application which holds all the data and generates all the reports and invoices etc and then have a third party application like we currently have and export our data to it / cross reference the integerity of our data to ensure we are not making mistakes and eventually transfers all the funds.

I know this may sound overly complex but I am looking at this development as not only a milestone in my development career (this being my first development role although I have been developing professionally for 18 months I am at least 18 months behind where I should be) which has progressed slower than i had originally anticipated, but also something that will provide a better cleaner solution in the event we decide to change our main invoicing/accounting package.

The kinds of resources that I am looking for are the kinds that will aid me in understanding how a finance system should be constructed in theory and what are the potential pitfuls/ quick wins (if there are any) that will help me develop a solution that won't need to have major recoding due to VAT rates changing or handling special tax requirements etc.

The current technology that we use is all MS based so SQL 2005/ C#.

Plus time is of the essence with this. Now I know that this is not a quick job and I would consider 6 months a possible time frame to get a complete working solution but the powers that be want it delivered within 2 - 4 months which I just don't think it can be done, or if it is then it is going to be full of potential holes and issues.

Again thanks all for your help so far.

slylittlefox · 5 Nov 2009 at 00:58

davetherave2 said:
well I work for an smb of around 100 - 200 people.

The intention is that we have a two tier finance system. We have the finance system which is internal to our application which holds all the data and generates all the reports and invoices etc and then have a third party application like we currently have and export our data to it / cross reference the integerity of our data to ensure we are not making mistakes and eventually transfers all the funds.

I know this may sound overly complex but I am looking at this development as not only a milestone in my development career (this being my first development role although I have been developing professionally for 18 months I am at least 18 months behind where I should be) which has progressed slower than i had originally anticipated, but also something that will provide a better cleaner solution in the event we decide to change our main invoicing/accounting package.

Plus time is of the essence with this. Now I know that this is not a quick job and I would consider 6 months a possible time frame to get a complete working solution but the powers that be want it delivered within 2 - 4 months which I just don't think it can be done, or if it is then it is going to be full of potential holes and issues.

Apologies, but from what you've described is going to be needed - you haven't got a hope in hells chance. Your one developer with only 18-months of professional development experience, who they want to develop a complete finance solution for a 200 strong workforce, and they want it done in 2-4 months? For a 'complete' finance solution, you're going to have to have an in depth knowledge of the theory behind database and system design, and then obviously the MSSQL and C Sharp knowledge to put the theory into practice. What's your background?

Quite simply, you should tell them it can't be done. It would take 2-3 developers 6-9 months to develop anything near a comprehensive, working system. Look at Sage - they have a relatively big team of developers, who've been working on the product for more than a decade, and it's still pretty crap. Speaking of Sage, though it has it's problems, it's still pretty robust - won't Sage 200 or similar meet their requirements?

If you do decide to go ahead as planned, understanding the current procedures/systems should be your first priority. By understanding I don't mean a one off meeting with the finance team, I mean everything, absolutely everything documented from top-to-bottom.

This stage will take around a month, if not more, and should end with you having produced a system proposal. You've then got technical planning, another month or two months. Then a recap with the finance team to make them aware of any changes to the original proposal you've had to make because of technicalities. That's then a couple of weeks of tooing-and-froing.

You're then looking at 2-3 months minimum before you'll have a 'functioning' alpha-stage system. You then enter the testing cycle, again, another couple of months.

Once you're at RC stage, you'll want to have the system working concurrently with the old system for a month or more, allowing the users to become familiar and for any final bugs to be ironed out. Do not have a 'switch-over' date - both systems should be able to work in tandem with each other. It will end spectacularly badly if on a Monday the finance team return to work and only have the new system to rely on.

In summary: you need to stop pretending you can do this on your own. If it's a 200 strong workforce, the company can't be short of cash. To be honest, I'd suggest outsourcing, and be in charge of liaising with the contractor, seeing through the integration of the new system. Alternatively, refuse to work on the project unless they take on a couple more developers (hopefully one of them having project management experience!).

There's two ways this could end up: 6-8 months down the line, you're still not near a workable system, and you're fired for not getting the job done. Or alternatively you can explain to them that this isn't a 'quick job' that can be done by one developer in the course of a couple of months, possibly get the sack for 'not being up to the job', or alternatively, they'll respect your honesty and your explanation of the problem, and put you in charge of the new team of developers

Whatever happens, good luck (you're going to need it!)

NickK · 5 Nov 2009 at 02:28

I have to agree with with Slyfox's comments.

Firstly - there is no silver bullet for these types of system. Every company has it's own ways and thus requires customisation in whatever way required. Cost effective implementors either use a COTS product that supports the level of changes within the COTS's development environment, or, they reuse a framework "solution" that they have created which allows them to make changes without needing to invent the wheel.
Creating a system, or reimplementing a system, from scratch like this is very expensive and time consuming.

What is extremely important to understand is that it will not be you using it or maintaining it (most likely) - so add training, ensuring you have a design that understandable and easily picked up is vital.

What I would do, is to say that you will spend 2 weeks timeboxed requirements capture (sat with the finance staff 24/7) with the start high level and broad. Once you have the system interfaces and basic usecases (I mean high level one liners) then make the next iteration pass to deepen it.
As long as you have some depth, you can at least make a finger in the air estimate - note that you should put in the risks and that these are minimum values.
At the end of the two weeks stop, regardless of state of completion and report.

What this will do is allow you to say a few things:
a) you know how broad it is (ie the number of usecases and other aspects),
b) you know how long it takes to capture one of those requirements in detail hence multiply by the number of usecases = the minimum time required to capture the requirements if you've not finished (approx).
c) you know, if you were to take an finger in the air average estimate of a couple varied and "reasonable" requirements (including design, coding, unit and system testing for that use case), treble the value and multiply by the number of use cases will give you the minimum time to get to the initial code release (alpha). Note this assumes no agile, task optimisation or tasks such as user manuals/training collateral, migration, side by side, fail over, recovery, performance, etc.

In this way you have only spent two weeks, built a set of figures that you can go back to them and say - these are my current estimates before formal estimation. It means that they can pull the plug earlier rather than later or, they can instantly see that they need additional people. If they add a cost of developers to that figure it may turn out cheaper to hire an consultancy that specialises in this sort of thing or buy a COTS product and pay for your training so you only have to make a few changes instead.

So next I would 'sell' this idea to them. It shows professional focus and it shows that you know what they're looking for - function, cost, time. If they cancel it, then you're only going to have a small waste of time that will be offset by the beneficial value that your research has provided. They may decide to take a new course of action and you become their "guru". I get the feeling that they want a solution but have no handle on it, so your research is valuable!

If they do get you to implement - print the entire requirements (usecase etc) document and get them to sign it. It sounds stupid but it will instantly make them feel that they're committing formally to it. If they change their mind or things are missing then you can push for change management (with additional estimates and time etc). I can see once they see they have a new system they'll pile in all those lovely changes that they've been saving because the current system can't be modified

I hope you entertain this suggestion - it will provide a lot of clarity and will answer a lot of your questions.

I apologise up front if the above is either patronising or repeats what you know - just my professional opinion based on 12+ years of solutions and product experience.

Now it's late I'm going to bed!

reefoid · 5 Nov 2009 at 08:01

My twopenneth, your going to need someone with strong project management skills to run with this. Don't know if you have PM experience, but a lot of what you'll need to do isn't technical, i.e. requirements capture, planning, scheduling, risk/issue/change management, etc.

If you don't have PM experience, I would advise you request someone who does to work with you.

And as NickK says, get the full requirements documented and signed off by Finance and senior management as early as possible so everybody knows exactly what is going to be delivered so there is no ambiguity down the line, otherwise it will be like trying to shoot a fast moving target.

davetherave2 · 5 Nov 2009 at 17:11

Again guys thanks for the additional information.

I have already done some background work with the users with their current system which I am currently maintaining but it is a struggle as it was not documented and implemented by previous developers who have since left.

I have had a number of meetings with the finance team to see what they do/ what works/ doesn't work and what we can do to improve the overall system for them.

I am currently at the start of pooling all the resources together that I have got from these meetings and reviewing the exisiting solution to see how it works and seeing if anything can be recycled as it were to speed up development time but I don't think much of it will be very useful initially.

Again thanks for all the insight and hopefully I can pull this off somehow.

slylittlefox · 5 Nov 2009 at 18:45

davetherave2 said:
Again thanks for all the insight and hopefully I can pull this off somehow.

You can't on your own! Seriously, you're making a rod for your own back by not speaking up now.

Seriously, you will look like more of an idiot, and doubtless get fired, if after six months of them paying your wages you still haven't got anything to show them.

suarve · 5 Nov 2009 at 18:57

Page rank

5

Whichever way you look at it, stuff like this is totally bespoke. Make sure you do your research and understand yourself, internal procedures.

Still, stuff like is ace to put on your cv.

DireEmblem · 5 Nov 2009 at 18:59

davetherave2 said:
Right long story short I am looking to create an internal finance system for an application that I have.

Currently the application uses a third party product and the data is pushed to the package from our application.

Due to our current system being a bit outdated and having so many patches/ remedial work done to it the decision has been taken to design and redevelop the system.

Depending if you are re-inventing the wheel for the whole system, or simply removing and updating a section in my opinion would determine if this is feesible for yourself or not.

The latter is more likely to be completed in say 4-6 months, as you already have a predetermined flow of data from other applications to base your model on, starting from scratch is a bit meh!

I would suggest nailing how information gets sent to/fro from each application you need to interface, and split your development up into building blocks, in order to track your progress/test each component.

Good Luck!

suarve · 5 Nov 2009 at 19:01

Page rank

5

davetherave2 said:
But boy did I underestimate the amount of work involve you mention a systems upgrade to finance people and they want everything plus the kitchen sink adding into the new system

That's of the problems with non techy people. They ask for feature xxx without realising exactly what a pain in the ass and the amount of planning/development time that feature takes to implement

To them (and rightly so ay I add), they just see it as 'make it do this'.

radderfire · 5 Nov 2009 at 19:16

Have you thought about looking at products already on the market, like accounting products from Sage.co.uk for instance?

Rgds

whitecrook · 5 Nov 2009 at 20:26

OT: what is tis page rank stuff that's appearing in your posts, suarve?

OP: This is a mother of an undertaking. Stuff like this takes guys that know what they are doing months even years to hone the system. I've found from my own limited experience that even 'simple' CRUD front ends to replace old access DBs take ages to set up and get working.

~J~ · 5 Nov 2009 at 23:54

To be honest this project is perhaps a major turning point in your career to become a "developer" and not just a "programmer"

I think it's perhaps unfair to say you can't do it because none of us on here know you well enough as a person either personally or professionally, so only you can know yourself. DO NOT kid yourself though, it really is going to be a huge task.

However, what I will say is this:

Everything you do, every form you create and every milestone you reach STOP take a break and give it to the users to test. They are the ones using it every day, they will be the ones to break it (and I guarantee they will), and they will be the ones who will be able to confirm as to whether each stage is working.

Start with something simple like the Account Management screen (where accounts are created: name, addresses, telephones, contacts, VAT Reg no, VAT code, bank code, sort code, discount code, payment terms, etc, etc) and then give it to them to see if 'essential' information is in place.

When they're happy, move onto stage 2, something like adding notes. I say this rather than something like an account history because chances are when you resubmit your program to test, users will suddenly say "Forgot to mention, can it have...."

DON'T add feature upon feature from the start, get a clearly defined path of what you want and stick to it. Save anything that's not essential to Revision 2.

Keeping it simple and within a reasonable project lifecycle will achieve several things:

You'll be able to provide visible progress on a regular basis, this will keep the users happy
You'll be able to fix the STUPID bugs from the start before they're embedded deep in the system
Any essentials 'should' be part of the back engine from day one rather than some payroll clerk several months down the road suddenly remembering they want "Customer Trading Duration" adding in to the database.

But more importantly, one thing that seperates you from the rest is that you'll actually be able to 'understand' the project, 'understand' the problems, 'understand' the whole reasoning behind the solution and this will turn you into a proper developer.

ANYONE can program, a good developer is one that provides a solution and to provide that, you need to understand the problem and learn how to fix it.

Personally I've got every faith in you.

See you in 12 months.