Pre JPA systems

[FOMz]

To be honest mate, if I was writing such a dissertation, I wouldn't use E-Goat as a reliable source of information. I have seen so many inaccuracies on here, that I suggest that you should chec k any information gleaned from here before you commit to paper.

If you want any particular question answering, PM me. I am sure that with 35 yrs experience as in the RAF in the Personnel world I might be able to point you in the right direction.

I would be very careful about putting yourself on a pedestal there FN. You may have 35 year experience being a scribbly - but it doesn't mean you know EVERYTHING, you may have forgotton a few things or memory becomes jaded with time. Also don't discount everyone else on here - someone may come up with the golden gem of informatipon the OP may end up looking for. The last person on here who did what you suggested came a cropper and ended up looking the fool...

 

[True Blue Jack]

The problem with coming to somewhere like e-goat for advice on a subject like this is that you get a whole lot of opinion which may or may not be backed up by useable fact. I also suspect that e-goat would not be an acceptable source for your bibliography!!

Every clerk of a certain vintage will tell you how wonderful SAMA was because we were very comfortable with it. Yet I remember that my first Chf Clk never took the dust cover of his SAMA terminal because he didn't trust it. I also remember that in its early life SAMA needed to be taken offline for long periods to run updates and that it crashed frequently.

Logging on to SAMA was indeed quicker than JPA but you were only ever accessing a local database. When it came to pay inputs, initially all SAMA did was to record that a form had been completed and despatched to Innsworth for processing. Later, we were able to use SAMA to complete the forms electronically which would transmit to Innsworth overnight. Even then, an office full of input clerks was required to plug the air gap FN was talking about. The advantage (and danger) with JPA is that every input effects the actual personnel record. Depending what you are doing, total processing time for a pay input can now be measured in minutes rather than days, and that includes the time taken to log on.

 

[poggy]

SAMA Systems

SAMA Systems

What about the joy of QR6 when wanting to interrogate the system! It was always a billy bonus if you had some geekish chap who really knew how to use it.

 

[northern]

Many thanks to all of you. I was initially after a high level overview on what was used but your discussions have given me a little bit more, that of the way you viewed your systems.

I am preparing a questionnaire for random units on JPA and from that I expect to get various levels of feedback along with personal opinion, which is what you all have offered and is something that I appreciate.

Many thanks.

 

[Humble Scribe]

Inputs to SAMA did not have a direct effect on pay, which was managed by a system called PSSL (no idea what it stood for, sorry). PSSL was a very simple but effective program written in a language close to machine code on an early era mainframe. Very good if you knew how to use it well but almost the only people who did were stereotypical long-haired, unshaven, sandal-wearing nerds (Humble Scribe is probably going to kill me for that!).

I'll let you get away with that dig as I guess you owe me one DT_Xtremez_14:

I guess the SWO at Innsworth would have been very busy if the 50 or so servicemen & women who worked in AIS 22 on PSSL turned up to work with long hair, unshaven and in sandals though!! (The dearly departed JP would have loved to have had long hair).

I don't recall what PSSL stood for, but I will find out; what I do know is that there wouldn't be so many pay issues and complaints that there are now under PSSL as we knew how it worked and how to sort issues out. We would actually talk to the clerks on the PD Points and between us get the pay queries fixed. There was a lot more servicemen around in those days too.

Under the program re-write (early 90's?) a lot more of the pay inputs became automated and because the clerks at the units didn't always understand how PSSL worked more issues arose and at the same time the long haired, sandal wearing brigade took over many of the posts in 22. You then had people who didn't even understand the rank structure let alone the pay processes actioning pay inputs (sound familiar?) which is where a lot of problems began.

I also worked on OMIS which was the latter day move & track system which relied on clerks calling in with specified data that we would key into OMIS. Very basic but there weren't all the Ops in those days and the constant need for stats that there appears to be now.

 

[metimmee]

Many thanks to all of you. I was initially after a high level overview on what was used but your discussions have given me a little bit more, that of the way you viewed your systems.

I am preparing a questionnaire for random units on JPA and from that I expect to get various levels of feedback along with personal opinion, which is what you all have offered and is something that I appreciate.

Many thanks.

I saw something recently about questionnairs within MoD (I'll be doing my dissertation next year, so I am interested). The thrust of the policy is that MoD Servicemen and CS are not to complete surveys unless they are authorised surveys. You may want to contact the DE&S colocation team at Abbey Wood who have published a number of large-scale surveys for advice. You could go ahead and ignore said policy, but it puts your survey on dodgy ethical grounds.

 

[CC]

The problem with coming to somewhere like e-goat for advice on a subject like this is that you get a whole lot of opinion which may or may not be backed up by useable fact. I also suspect that e-goat would not be an acceptable source for your bibliography!!

Every clerk of a certain vintage will tell you how wonderful SAMA was because we were very comfortable with it. Yet I remember that my first Chf Clk never took the dust cover of his SAMA terminal because he didn't trust it. I also remember that in its early life SAMA needed to be taken offline for long periods to run updates and that it crashed frequently.

Logging on to SAMA was indeed quicker than JPA but you were only ever accessing a local database. When it came to pay inputs, initially all SAMA did was to record that a form had been completed and despatched to Innsworth for processing. Later, we were able to use SAMA to complete the forms electronically which would transmit to Innsworth overnight. Even then, an office full of input clerks was required to plug the air gap FN was talking about. The advantage (and danger) with JPA is that every input effects the actual personnel record. Depending what you are doing, total processing time for a pay input can now be measured in minutes rather than days, and that includes the time taken to log on.

TBJ, granted, but you're just looking at the pay element of JPA. As a Personnel system, it is simply rubbish. Checking of NOK details, addressess, etc, takes far too long. Hence the reason many units have devised their own downloads.

I believe, pre JPA, the 3 services all had 100s of different systems that couldn't talk to each other. We get JPA and what happens? Excel becomes our main application and we replace the 100s of different systems with 1000s of different spreadsheets.

 

[busby1971]

TBJ, granted, but you're just looking at the pay element of JPA. As a Personnel system, it is simply rubbish. Checking of NOK details, addressess, etc, takes far too long. Hence the reason many units have devised their own downloads.

I believe, pre JPA, the 3 services all had 100s of different systems that couldn't talk to each other. We get JPA and what happens? Excel becomes our main application and we replace the 100s of different systems with 1000s of different spreadsheets.

This is the problem, we should work with JPA as it is we should not do things that we used to do, problems should be high lighted and JPA updated. We no longer have the staff to do what we once did, the services agreed to down grade to JPA and cut the staffing to reflect this.

If people cannot be bothered to update their NOKs then they need to be educated about the consequences of someone knocking on the wrong door or their families not getting there in time of a serious injury, not a multitude of gash spreadsheets floating around and flaunting DPA rules.

Clks keeping spreadsheets reminds me of the old school Chf Clks making hard working PSF P and A Clks maintain both SAMA and Cardex just in case.

 

[CC]

This is the problem, we should work with JPA as it is we should not do things that we used to do, problems should be high lighted and JPA updated.

And here lies one of the main problems with JPA, to get any update costs thousands and takes about 18 months. Consequently many updates never happen.

The system was not fit for purpose but we still had to make it work. Problem is, today, we still have workarounds being passed down from higher authority.

As for NOK details, it's alright preaching that but in reality it still makes no difference. On my last OOA, I was aware of some KIAs that had incorrect NOK details but questions still went back to their rear parties asking why that was the case.

It's a self service process but the clerks still get the blame for incorrect NOK details.

 

[knarfw]

When I first did pay as a rookie PandA Clk it was still mostly manual using the GCIs (Guide to Cash Issues) and the Q6 (Form 6666 Pay Statement which was a long red form always a month behind). The GCI gave you 28, 30 and 31 day net drawing rates and you manually entered changes such as refund of food (RFF) for leave, start/stop rent etc and adjusted the month's pay accordingly. The Q6 also had a carry forward balance which had to be checked and adjusted accordingly. The figures on the GCI/Q6 were changed by submitting forms (tear off portion of leave pass for example) through the mail to PMC which could take a while to 'hit' but if the clerk had done their job properly it didn't matter as changes would be manually corrected until the input 'hit'.

Then along came CBPS (Centralised Bank Payment System) which was a nightmare as it took the manual adjustment capability away from the clerks and meant that pay was totally messed up until the inputs, still submitted by mail, hit. Then along came SAMA as explained above and JPA which I Missed thankfully.

 

[Witty_Banter]

To answer the original question:

Before JPA, we had Admin Clerks. They were a strange creature, only ever in abundance when you didn't need one and rarer than a solid gold Mars Bar when you did. They used a magical concoction of ink and paper, delivered from an un-ending supply of pens (not that I could ever find one in work...). They were troublesome, annoying little oiks, but they knew their jobs backwards and inside out and could get the most bizarre requests and worrying pay disputes sorted out in mere moments... if you asked one nicely...

They were replaced in approx March 2003 by the almighty JPA, which stands for Jacked-up Pain in the 'Arris. This system was then used to obliterate the careers of thousands of Admin Clerks; since it's first job was to destroy it's masters, JPA went slowly insane and is currently on intense medication, unable to work properly since that very day.

It is highly likely that, should JPA survive the third round of redundancies, it will be shortly placed on Medical Discharge pending psychiatric evaluation. It's inbred cousin, DII, is currently exibiting similar signs of emotional breakdown as it faces divorce from it's newlywed partner, MOD (MOD has recently rolled into bed with MOSS, as DII was crap at most simple, everyday tasks and couldn't cook). Whilst this newer, younger model is yet to be properly flaunted to MOD's family, we are all expecting it to be closely related to the same gold-digging family as DII, and for MOD to be properly fcuked over for loads of cash and bum-raped into paying for it's high-maintenance lifestyle...

 

[dkh51250]

And any query passed to those Clk Secs/P&A wallahs was answered instantaneously if biscuits were added to the equation.

 

[stereolab]

Gone but not forgotten

Gone but not forgotten

And any query passed to those Clk Secs/P&A wallahs was answered instantaneously if biscuits were added to the equation.

Also remember the cream of the crop, Clk Acctg and Stats Clk, the latter off course being of no use to most folk, but they would still take your biscuit.

 

[veryretiredscribbly]

You guys must have had the "interactive" version of SAMA for "real" clerks.
All we ever saw was the dumb terminal which was (to be honest) little more than a faster version of the phonebook.

We finally got our terminal in '94 (or thereabouts) and it sat on the middle of partition that kept the officers out of the registry proper.

I'm pretty sure our PSF stuck with doing paperwork & SAMA for as long as they were able, belt & braces approach I guess.

 

[stereolab]

You guys must have had the "interactive" version of SAMA for "real" clerks.
All we ever saw was the dumb terminal which was (to be honest) little more than a faster version of the phonebook.

We finally got our terminal in '94 (or thereabouts) and it sat on the middle of partition that kept the officers out of the registry proper.

I'm pretty sure our PSF stuck with doing paperwork & SAMA for as long as they were able, belt & braces approach I guess.

In 1993 our new SAMA machine had twin floppies, one used as a hard drive!!!!. How that company Akhter conned the MOD is still a mystery to me.

 

[Barch]

In 1993 our new SAMA machine had twin floppies, one used as a hard drive!!!!. How that company Akhter conned the MOD is still a mystery to me.

Probably the same way that the providers conned the MoD with DII.

The MoD will be always be in trouble until it wakes up and realises just that service contract on each local network PC would buy a state of the art PC from [spit] PC World 10 times over.

I just wonder how many favours / back handers etc are made before these kinds of contracts are signed.

 

[metimmee]

Many thanks to all of you. I was initially after a high level overview on what was used but your discussions have given me a little bit more, that of the way you viewed your systems.

I am preparing a questionnaire for random units on JPA and from that I expect to get various levels of feedback along with personal opinion, which is what you all have offered and is something that I appreciate.

Many thanks.

Have you got your ethics approval sorted for your questionnaire or will it be anmonimous? I nearly came unstuck during my dissertation due to this. There is a JSP which gives details on how to apply for ethics approval for research in the mod involving human subjects. I dont have it to hand as im sat by the pool in 40 degree heat.

Unfortunately my university were well versed in this jsp and it became a last minute faff that I didn't need.

That's quite a high word count...are you studying Mphil?

 

[CodeMonkey]

Have you got your ethics approval sorted for your questionnaire or will it be anonymous? I nearly came unstuck during my dissertation due to this. There is a JSP which gives details on how to apply for ethics approval for research in the mod involving human subjects. I dont have it to hand as im sat by the pool in 40 degree heat.

Unfortunately my university were well versed in this jsp and it became a last minute faff that I didn't need.

That's quite a high word count...are you studying Mphil?

Slightly Off Topic
Do you remember the "anonymous" medical questionnaire(Kings College London) that was doing the rounds in 2004/5(might be a year out) that turned out not to be that anonymous because OC PMS sent an email to all sections with names/number etc of all personnel that had not returned it. I'd flat out refused to fill it in because it was obvious that the MOD had given out personal information and this survey could be tied back to it.