|
|
|
ROCS Update – December 2001
(As there are a number of new recipients of this email, let me explain what is going on here.)
My intent of this monthly update is to keep current and potential users of ROCS updated on what I have been working on in the last month, and what new projects I am working on. I will also use this email to update the delivery schedule, and alert users to updates on the website.
The last month has been a very busy one with special events at the M&E and setting up the EDI version of ROCS for the SRNJ, so there is not much to talk about new features. I can report that ROCS is still functioning with no problems at the M&E, and that both intentionally and unintentionally I have tested most of the safety features in the program.
What I would like to do this month is talk about Short Line Data Systems Inc., which is the company I formed a year and a half ago to market ROCS. I think it is necessary at this point to discuss what my business philosophy is, and how SDS should grow in the future.
Let’s start with what is probably the most important question: Why am I doing this? The answer is relatively simple. Over the last seven years, I have developed a Microsoft Access database to handle a growing number of operational and customer service functions at the M&E. We became a user of the RMI IRCS package after Railinc dropped support for their TRUMPS software, and the database was developed to cover a number of perceived shortcomings with IRCS, and the need to stop doing a number of repetitive tasks manually. We really needed to go from pencil and paper to the computer age. For the first five years or so, the database that was to become ROCS was just that: a rough database with a number of reports that we would print out for our own use or for faxing to customers, but nothing more than that. About two years ago, during a phone conversation with Bob Bailey of the Port Jersey Railroad, he was complaining to me about the high cost of car hire billing, upgrades to software, and how difficult it was to get what he needed from RMI.. After a little thought, I told him that he could probably use a version of our Access database, and solve most of his problems. Discussions followed, and he convinced me to start developing a marketable version of the database.
Over the next four months I worked on the user interface, or the “faceplate” of the database. The program developed, and as everything in the rail industry requires a witty acronym for a name, I decided upon Rail Operations and Customer Service system, or ROCS (the PDA version of the software will probably be called Pebbles or Sand, but stay tuned for it). I also decided on a couple of firm policies of SDS:
In April 2000 I demonstrated the first user version of ROCS to the Southern RR of New Jersey and SMS-Penn Jersey Lines, and they became the first customers of SDS on the spot (Port Jersey signed on a little later). When they signed on they requested a schedule of when a full IRCS replacement would be ready, and I gave them an estimate of 12-18 months. As I developed the EDI portion of the program, SRNJ and SMS started using the non-EDI version of ROCS. As 2001 progressed, the M&E started beta testing ROCS 2001.3 (full EDI) in early August (16 months after start of development), and switched over to ROCS for all EDI functions in late October. SRNJ will have ROCS 2002.3A (full EDI) at the end of December, and SMS and PJRR will receive the program in January 2002.
A common question asked in Jacksonville a few weeks ago concerned the current size of the company. Yes, right now SDS is a one-man show, but that is not the case for the future. As the number of ROCS users increases, I have a group of people that will increase their involvement with SDS. One of those people is currently working for one of the major book wholesalers and has developed an Access database for their use in tracking sales. He is currently working on documenting what I have written for ROCS, and will be involved with quality control and program development. One other person who will help with customer implementation has been involved with database implementation for the Bayer Company (yes, the aspirin people). My intentions are to grow the company as needed, and keep the overhead as low as possible to keep your costs low.
I think I’ll close this month’s update with a little piece of news: in Jacksonville I had the chance to talk with my friends at Railinc, and they encouraged me to get the FTP communications up and running soon, as they will be ready to support it shortly. The FTP will be one of the keys to the forthcoming in-house car hire system, and will make communications much faster. The other tidbit is that ROCS will be compatible with Railinc’s Concur interline settlement product, so if you are thinking going ISS or are currently ISS, ROCS can work for you.
Also, I am going to throw a question out into the ring. While I developed ROCS around how we have done business at the M&E, I know that everyone does things differently. What I would like to know is what do you think should be added to ROCS that would work for your railroad, and what would you like to see any railroad management software do that is not being done now. While I can’t guarantee that your suggestion will be the next major upgrade to ROCS, everyone will be looked at and responded to. E-mail me at sfriedland@sdsrocs.com.
As always, I am available to answer any questions you might have about ROCS, and can arrange a demonstration on relatively short notice. There will be an update on the website (www.sdsrocs.com) in a week or so, and if anyone would like one, there will be more copies of the full brochure available soon.
Steven Friedland |
Send mail to
webmaster@sdsrocs.com with
questions or comments about this web site.
|