Cyril / Hugh/ Yogesh
The scope of work is schematically described in the
enclosed diagram. The basis inputs are TEXTS of various types. The printed
texts will be scanned and subjected to an OCR software to convert into ASCII
files. Then, there will be texts received
ELECTRONICALLY such as
- Floppies
-
Fax
- E
: Mails
- Computer files (Dial - Up / Internet /
Intranet)
In both the cases, the software will search,
identify and pick - out KEYWORDS and place them in appropriate BINS/ FIELDS,
based on the "meaning" of each keyword. In this way, the software
will Create a database (or several databases). This basic process will remain
the same irrespective of the type / size / structure / format of the document
being scanned (whether printed or electronically received document).
Of course,
all the keywords picked - out from a given document will be linked to that
document (identified as belonging to that particular document).
Having created a DATABASE, it should be capable of
being QUERRIED, by using any of the KEYWORDS (one or more, in the AND/ OR
fashion). For each keywords "SYNONYM RINGS" WILL have to be created.
The search will produce a short list of all the
records (documents) where such a designated / specified KEYWORDS appears. We
should be able to VIEW all such records on the Screen (one by one) or be able
to take print - outs.
By using a computer - memorized STANDARD - LETTER,
we should be able to send - out the short - list to a given client.
Besides responding to a QUERRY shot from one of our
own LAN Nodes, the software must permit a client to shot such a query from his
own office computer by remotely logging - on to our Server thru a dial - up
Modern or thru internet connection. This feature (of remote query) is
absolutely essential. Of course, we must provide for a password within a
password within a password (!) to ensure data - security.
of course, what part of the database each user will
be allowed to access (locally or remotely) will be strictly defined in advance
and rigidly administered. The users are :-
- Self
-
Associated (e.g. Mankodi/ Gangolli etc)
- Candidates
-
Clients
-
Foster Partner Member and may be
- Anyone from Public.
What is expected of the software is REMOTE ACCESS
CAPABILITY. And that should be built into the Software RIGHT NOW.
However,
Which user will be allowed to remote access
What databases and shoot
What type of quarries and
When (point of time)
Will be spread - out over next 2 /3 years.
However, in the first phase itself.
We want
1. Candidate
to enter and modify their own biodatas remotely (This is the ONLY WAY, we can
hope to build up a
- Large candidate database
-
Quickly
-
Without hiring an army of data - entry operators or persons to scan typed bio -
datas.
2.
Candidates to be able to shoot queries to JOB BULETIN BOARD. This is the MOST
POWERFUL VALUE - ADDED SERVICE (VAS) as far as employment / change - seeking
executives is concerned. This VAS will be available only to those executives
who register / enroll with us by
-
Remotely entering their biodatas
- Sending
biodatas on floppies.
Once
again, the idea is to transfer the data - entry burden onto the candidate
himself.
3. Clients
to be able to shoot "Executive Search Queries" remotely (from their
own computers) exactly the way we would have done locally. The software will
search and tell the client (or potential client) "How many suitable
candidates we have in our database? - a number" Nothing more ! But this is
a great way of HOOKING him ! If his need is really SERVIOUS, he would, next
day, send a cheque (advance) along with search Request !considering that it
would
- Cost him
over a lakh of rupees to adventure that vacancy
- to take
him 8 weeks to get response,
The bait of REMOTE ACCESS/ IMMEDIATE ACCESS/ CHEAP
ACCESS is simply irrestible !
This is an IMPORATANT aspect of the cost-Benefit analysis
of the software to be developed .
The rest of the REMOTE ACCESS applications can wait
for 2/3 years – as each database gets built-up by scanning thousand of pages of other documents, some of
which are enclosed herewith.
h.c.parekh