Opening the discussion

[Mark Hughes]

Right,

Just to kick this off, as I think we've got a reasonable amount of
members to make things meaningful now..

I'll start by saying the draft specification thats up there is not
perfect (and if I can criticise my own work, please can everyone else
feel free to do so!).

The faults / issues as I see them are as follows:

1) There is some overlap / duplication between some points in the
specification..e.g. points 15 and 96
2) Does not cover ISO 28560 (I know its not in place yet, but only a
matter of time...)
3) It tries to inform suppliers what needs to be achieved, but not
restrict how thats done, which I think is the way to go, but some
specifications might not allow enough 'room for manoeuvre'
4) Maybe there should be more emphasis on open questions & narrative
explanations from suppliers, rather than some fairly 'closed'
questions.
5) It doesn't really address having a supplier 'prove' their system
can deliver some functionality...but maybe thats a function of
supplier demonstrations?
6) There's other bits of functionality not covered I'm sure...

So, anyone agree / disagree? What could we add / remove / change to
improve this?

Thanks

Mark

[Mick Fortune]

Hello Mark

Having just been through a 3 hour review of the Kensington and Chelsea
Functional Requirement only yesterday the challenge of drafting
something that delivers for both the institution and the supplier is
still very fresh in my memory!

Recalling the invitations to tender I saw during my time at 2CQR I
remember the total frustration I felt in having to answer some highly
prescriptive specifications that completely denied me the opportunity
to raise questions, suggest alternatives or examine what I saw as key
issues in implementing any RFID strategy so I agree absolutely with
point 4.

There are some very different approaches to RFID implementation out
there in the market as we both know, so it's quite important to ask
questions that will help reveal the differences between the companies
and their strategies. A simple shopping list of equipment - as
encouraged by subscribers to the ESPO framework or Catalist programmes
- will tell you nothing about the philosophy behind an RFID strategy.
Conversely defining an imagined (or real) methodology for say,
perfoming stock checks, might rule everyone out. Quite often libraries
will compromise on the responses they receive in order to ensure that
SOMEONE passes the finishing line - which is OK until they forget that
when the actual implementation takes place, resulting in
disappointment all round.

Personally, and I have laboured this point ad nauseam I know, I find
it difficult to consider RFID implementation is isolation. Introducing
a new application and technology into what may often be an already
fragile IT infrastructure without dialogue with all the parties that
will be required to work together to create a working solution, seems
problematic at best and downright dangerous at worst :-)

All of that is just my opinion of course - but you did say you wanted
to get things rolling...

Kind regards

Mick

[Mark Hughes]

and we're off...

Thanks Mick & welcome to the group!

To just add a little to this.. I think there's a couple of key
concepts we need to think about..

1) What is the point of a specification... Overall I think it should
a) set out the basic functions required from the system (e.g. it deals
with RFID items, you can issue, return etc..) , b) it provides the
supplier with a context (x amount of tags, x amount of sites, overall
aims of y), and c) the replies should enable libraries to
differentiate between suppliers and systems on offer
2) ..which is where more 'open' questions are needed.. The problem
with having too open a set of questions & replies is how do you then
'score' those as required by procurement rules..and interpretation of
such replies also requires a reasonable amount of knowledge on the
scorers' part which they may not have unless they've worked with RFID
before.
3) So you need a balance between open and closed.. As I said that was
what we tried to achieve with this tender, but I do feel that we
didn't get it 100% right. Hopefully with input from others on here
that can be improved.
4) In terms of involving all parties in a procurement, I think thats
fairly common - both procurements I've done have had input from
Libraries, IT depts, Legal Depts.. Problems can arise with the 'too
many cooks' issue, especially when people outside of Libraries who are
involved will often know very little about RFID or how libraries might
want to use it. It is sensible to operate that way, and it can work
well, but whoever is leading the procurement needs to have a strong
personality to keep things all in check, and a pretty good knowledge
of RFID & Library systems to keep discussions on track.

Maybe point 4 is more appropriate to discussion around procurement
guidelines? Should we, as a group, look at advocating the use of the
BIC Guidelines alongside this spec, and if so, are there any means to
feed into that for future revisions?

Thanks

Mark