Notes

Tuesday 7 January 2003

Monday 6 January 2003

PYRAMID OF PRODUCTIVITY

Abhi

Enclosed find a conceptual framework. It is by no means "comprehensive". I am sure you can improve this.

What made me draw - up this pyramid? what "triggered" it?

I thought of this when you told me that before consultants can re - start using debugged OES, they would need to enter, all over again COMPANY MASTER/ LEGAL MASTER. This is a colossal Waste of time/ energy - but, perhaps, cannot be avoided, at this stage.

Q -

What can we / must we do NOW, to ensure that history does NOT repeat, in case of all of our applications? Not matter how many "revisions/ debugging" these applications may have to undergo?

Possible Answer?

MASTERS/ DATABASES/ SOFTWARE TOOLS must not be an integral - part of ANY application. These must be stand along / isolated. Any user/ user - group should be able to use any application any time. and any way (LAN/WAN/Dedicated Line/ VPN/Wireless devices etc. etc), without having to meddle with

. Masters

. Databases

. Software Tools

All of which must independently work in the background.

No user should be able to add/ edit/ modify/ delete, any Masters/ Databases/ Tools.

Our Data/ Network SECURITY SYSTEM, Should only define, Who (user/ user group) can access & use, what/ which application & how (local/ remote etc). And it must keep a log of every use by every user (transactions/ mouse - clicks / key strokes).

"MASTERS" will flow to databases/ software Tools & Applications but independently "reside" somewhere else - beyond every user's "REACH" ! only DBA can touch them.

Perhaps, we can allow 3P's own employees to be able to "see/ view" these MASTERS and suggest additions/ detections/ modifications to DBA, only who has "access" to the masters.

When a "Developer" designs a new application/ software tool/ database, he should not have to worry/ think about the MASTERS.

And obviously, a MASTER remains a MASTER, irrespective of the application!

e.g.

You cannot have "separate" Company - Masters for

. Member Database

. Non Member Database

. Module 1

. OES

. Compiler

. Manhattan

. Jaws

. Web service etc.

cc: Raju - Sri Ram - Nirmit

cc: Kartavya - Inder - Reena

cc: Deepa - Reji - Vikram – Sunitha

h.c.parekh

Friday 3 January 2003

RATIONALISATION of “MASTERS”

3 Jan 2003

SriRam/Raju

RATIONALISATION of “MASTERS”

In our Masters we have

- 200 Industry Names

- 100 Function Names

Some I months back, Abhi had done an A-B-C analysis of these Industries/Functions and found that

- 80% of resumes received (whether web forms or email resumes) belonged to, may be

· 20% of “Industries” and

· 20% of Functions”

- Absolutely No resumes were ever received against

· 50/60 Industry Names

· 0/30 Functions Names

Based on these findings, I had drawn-up a Rationalization (Reduction) PLAN. This (plastic) folder was given to SriRam/Raju, some 2 months back.

Now, we are at a stage, where we must finalize this “rationalization” by this SUNDAY. Unless we do so, we cannot proceed with some important software Tool, o which we are working for last one week.

Therefore, I suggest that 3 of you sit-down this SUNDAY and finalize the same. If you wish, myself – Kartavya-Abhi-Inder would be happy to join you. Please advice.

Although, I don’t think it is necessary, if you wish Abhi, can today once again run ABC analysis of all 72000 resumes (Industry wise/Function wise breakup). In any case, Abhi should be in a position to modify these MASTERS on Monday in

· Website

· Module 1/OES

· Several Software Tools

· Offline Job Advt / Resume CD’s etc.