During our tenure as CIOs, we try our best to serve the organization that we work for, through the deployment of IT solutions. We consider the company’s strategic direction, business objectives and goals, and we help achieve these ends.
Our effectiveness often depends on the quality of the business strategy and plans drawn, and the focus provided by the business. If the business guidance is clear and the CIO is also senior enough to participate in the strategy discussions, a meaningful IT plan can emerge. However, more often than not, such situations are a rarity and the CIO has to chart out his own path.
The CIO draws out his plan of action, and acts within the limitation that he faces in the organization. Many a time, he ends up addressing issues of cost reduction and enhancing efficiencies as the immediate needs of business and feels happy if some of these measures are successful. These measures no doubt remove bottlenecks and bring benefits to the business in the immediate scene; but may not be enough to help the business in the long run. For example, these measures may help the company in making the processes faster and better and improve profitability in the short term; but it still would be an inward looking measure reviewing ourselves, without considering various stakeholders that we serve.
Where is the customer?
Sharing an experience of mine may help driving home the point. I had once drawn out a comprehensive IT plan for my organization, and shared it with all the senior management personnel. While others did not have anything significant to say, our MD wasn’t satisfied and said that he read a lot of pages but did not find any mention of the customer, the one who is the key for the future of our business. Though I took an initial dislike to his critical comment, I realized it a little later, and then expanded my thought process to include what he expressed.
Now if we look at the business the way a CEO would view, we would realize the importance of considering the entire eco-system in which the company operates. We may make the company efficient; but unless we take care of the markets, the customers and their needs, our efforts may be inadequate.
Is your IT plan comprehensive?
Companies do not work in isolation and have to deal with a number of outsiders like suppliers of raw materials, other vendors, dealers, customers, etc. Instead of looking at efficiencies at our workplace alone, it would be better to ensure that the entire chain works efficiently.
Therefore, the IT plan would not be complete unless it explores the best way for getting all these constituents to work together to achieve synergy. For example, if we connect with our suppliers to let them know of our plans in advance, they would be ready with the supplies, obviating the need for follow ups and also that the suppliers will be able to manage their stocks better.
Similarly, the dealer can send his requirements on time and can view availability to modify his orders. If such a synergy could be achieved, it will not only make the materials move smoothly, it will help reduce costs and ensure timely deliveries of products in the markets. It is important to pay attention to the customer and winning his loyalty, by providing the facilities of online ordering, or online viewing of status or recording of grievances.
The CIO therefore should shed narrow focus and look at the broader canvas of business that he can run his brush through. It is not just about enhancing business profitability but to ensure constant growth and longevity of business.
Whenever we start with a mission or with an objective, we are bound to face hurdles. Every journey is an adventure and we need courage to go through and win at the end. We undertake similar journeys when taking up systems for computerization. When doing so, we look at various steps in the process and try to automate them and also look at modifying the process or to eliminate certain steps that, in our opinion, are redundant. You may call it process reengineering or process improvement; but the fact is that processes do need to undergo changes when automated.
This is where the real test of the CIO comes to the fore. Resistance to change is normal and many reasons are usually put forth by the users to justify it. There are two ways in which the CIO can deal with this situation. He can either take an aggressive stance, take risks and push for full automation of the processes; or succumb to pressure and compromise on the solution and automate partly leaving some of the steps in the process to be done manually.
I have seen such situations often, either being directly involved as a CIO or having observed as a reviewer or consultant. It is very often that these difficult situations are evaded and an easy non-controversial path is followed that tries to accommodate the objections of persons who do not want things changed. The result is a compromise. When that happens, parts of the process are fast and efficient yet interspersed with manual and ineffective steps. The full process chain is therefore affected and the benefits of automation are not realized. I consider these partial automation cases as bad examples and not really worth emulating.
Let me cite a few examples of partial automation. As a CIO I initiated the work of automating the process of expense reimbursement to employees through vouchers. The manual process involved the employee preparing the voucher, getting it okayed by the head of the department and then forwarding to the accounts department for verification. Whenever the voucher was ready, he would go to the cashier to collect the money. Automation of this process involved the employee preparing the voucher on the system and forwarding it to his superior for approval which then would automatically flow to the accounts for verification. But it still required the employee to physically go the cashier to collect his money depending on the timing of the payment window. I then had to put my foot down and convince the accounts department to transfer the payment amount directly to the employee’s account with the bank.
Similar was a case in another company where the process of approval of special discounts required approval of the vice president – marketing. Since the VP himself was not comfortable using the system, he insisted on this part to be a manual process as he did not think approval through the system was secure enough. It needed considerable convincing to bring him on board.
I was recently reviewing a few processes in the Government bodies as a consultant. As it happens in most places, some departments were very good and some others tried to compromise. For example, there was a department that went for complete automation, in which papers needed to be sent from one section of the government to several others, but the responses could be received directly through the system. In order to ensure security, they introduced digital signatures and officials were reminded about their responsibility to keep their accounts secure. In contrast, another wing of the Government preferred to automate all processes within their department; but when approvals and responses were to be got from other departments, they were asked to take a print from the system, sign and then deliver.
Systems, when automated fully, run smoothly and provide the much needed efficiency; and the environment is devoid of papers floating around. Partial automation cases however are inefficient and carry along many of the problems associated with manual systems.
There is no doubt that technology helps bring efficiencies in our operations, decreases turn-around time of transactions, brings transparency, helps exercise control, etc. The right use of technology, of course, gets us all the intended benefits and makes our life easier. However, a wrong choice of technology or an inappropriate use defeats the purpose, and besides delaying the project, it causes loss of morale and financial loss which could be hard to justify. I have seen these situations occur in the following circumstances:
1. When the CIO gets enamored with a new technology and decides to gamble without adequate study and/ or invests in it a little too early—before the technology matures.
2. Inappropriate choice of technology; getting carried away by vendor’s sales talks.
3. Under pressure from users who cite examples from other places and thrust a decision down the CIO’s throat.
Let me cite a few real business cases that I have observed as examples of failures:
(1) Implementing Bar Code: In an automotive company, we had users who had just returned from a visit to the collaborator’s plant abroad. Keen to prove their smart ways and of having learnt something new, they proposed implementing bar codes for monitoring material movement in the paint shop. When they approached us for PCs, we raised a few questions on the process suggested. Unable to answer, they went back and procured the PCs separately from their project budget. Since the whole process was misconceived, it died its natural death and the PCs had to be diverted to some other users in the plant.
(2) Thrusting RFID solutions: When RFID came into the scene a few years ago, it was touted as the next big thing and many organizations were tempted to adopt it. I too experienced this pressure from our manufacturing wing who wanted to track movement of materials and vehicles in the plant. When confronted with the fact that any material entering the manufacturing process completed its cycle in 36 hours, the users beat a retreat. But I am aware of many organizations who tried various pilot projects only to shelve them after a while. I am laying emphasis on the fact that a detailed study should precede the final decision on the project.
(3) VOIP phones: On joining an organization, I was surprised to see a VOIP phone placed on my table which did not work. On enquiry, I was told that my predecessor had got installed a dozen phones to bring down STD costs. Well, the connection never worked well, and the users too did not find it convenient to use. Later, as the telecom charges dropped, the project was quietly shelved, though not formally closed.
(4) Mobility solutions: Under pressure from the management to bring innovation in the markets, the sales department decided to implement sales force automation system. The objectives were, however, not very clear and the whole purpose was shrouded in generalities. They went full hog and collected a lot of data from the field; but the use of data for reporting and analysis left much to be desired. They were at a loss, explaining to the management the justification of the investments made and the benefits that they could demonstrate. The money and resources spent did not yield appropriate results.
(5) GPS: I came across an instance of a transport company wanting to install GPS based monitoring system in all its vehicles which numbered a few thousands. When asked about the specific objectives and advantage that they thought would accrue, answers were vague and packed with several long winded explanations. As some of the earlier technology projects went off well, the CIO wanted to do more and impress, but I thought that was a pure gamble.
Any technology project therefore needs to be taken up with due care. Clear definition of objectives, detailed study of the processes, consultation with all stakeholders, and a clear assessment of the intended benefits versus cost are absolutely essential before starting on any such adventure. Well implemented systems succeed in creating an impact and go further building on the gains, but inappropriate use puts the organization in big trouble and should be avoided.
Of late, I have been visiting IT deployments in many small and medium organizations — in the private sector as well as the Government sector. During the process, I had the opportunity to study initiatives taken by the business, as well as the IT support necessary to make business succeed.
In many such cases, the IT group helped in making the organization more efficient; enabling them to respond well to their customers and successfully roll out e-Governance initiatives. Some of them appeared very successful ventures, and showed a lot of promise. In the case of a few others, I did not find the IT response to be adequate. Though everyone seemed happy with the situation, a closer look gave a feeling that the gains were not sustainable given the inadequacy of the IT infrastructure that supported these initiatives.
Let me explain the issue further. A meaningful IT support to business begins with a plan, a strategy and a definition of a roadmap for the long run. Sometimes this is ignored in the interest of immediate gains, and at other times this aspect is not properly understood. I will list out a few situations to drive home the point.
Piecemeal solutions over time: This is a usual phenomenon noticed in many situations. Each requirement expressed is converted into a system, and programs written to roll out for implementation. Several systems then get developed, often by different programmers, and on a variety of platforms. Whenever the need for an interface arises, some element of data passing or a loose integration through Web services makes everyone happy. Little do they realize that it is these ad-hoc solutions that lead to an avoidable mess as the needs expand, and several solutions get developed.
Total reliance on in-house staff: In several cases, people take pride in announcing that all systems have been developed in-house, and that there is no external input. The impression given is that they have saved costs for the organization, and that the internal staff is good enough to handle all organizational needs. The trouble in such cases is that the group’s knowledge does not grow, and they keep doing what they know. This aspect is reflected in the way the solutions are developed, in the way hardware platforms are chosen, and the manner in which systems are written. The methods at times are outdated, and lack a contemporary approach.
Lack of participation at the management level: Unless the IT head is senior enough and participates in business discussions, the solutions will always be ad-hoc, and lack a long term vision. I have met a few managers who were fully involved in the business initiatives, and were well aware of the business directions and goals in focus. Others were happy to play a background role — the solutions they developed were suspect, as they could have not have held when the business expanded or when the situations got complex. Such an approach remains to be one of a programmer, who only looks for an opportunity to write a program.
Make do with small IT teams: I was surprised to hear from a few Government departments about their achievements in spite of being a small team. They spoke of economizing on budgets and about outsourcing. I thought many of them did not understand the importance of IT, and thought that by outsourcing system development they had done the right thing. There was still no IT direction and their moves were dictated by the appointed vendors.
From all these situations, I learnt that managements which drive such initiatives should ensure that IT solution infrastructure is aligned to organizational growth; that built IT platforms will last for the next few years. It is also important to ensure that the technology is suitably updated, so that IT gives them an edge, and that the organization benefits from technology usage.
We have been speaking about going paperless for many years now. People initially were very skeptical and said that this can never be achieved. However, as technology progressed, a paperless scenario looked more real. The advent of e-mail facilitated putting many a memo, word files, and excel sheets in e-forms, thus, avoiding a print on paper. However, the drawback was that it left a lot of organizational information scattered, and worse, lying on individual PCs.
I have experimented with technologies like document and content management, work flow, microfilming, etc. which have brought in a lot of relief and the attendant advantages. The implementation journey and the transition were however not easy and we had to face several hurdles. But even today it remains quite a challenge and it certainly is not a cakewalk in most places. Let us look at some of the factors that hinder progress on this front.
Removing the roadblocks
1. Breaking the habit: People who have been used to keeping papers in files cannot easily give up the habit of storing records physically. They still print the documents with the plea that they are uncomfortable reading large documents on screen.
2. Inertia in classifying and organizing documents: We usually ask users to group and classify their documents subject-wise so that they can be organized and stored in a central repository. Many do not cooperate saying that their classification changes often as they handle new subjects often. Some are so used to creating ad-hoc directories in their PCs that they are not amenable to taking a holistic view and creating a new order. This one stage I have seen taking inordinately long.
3. Plea of flexibility: Keeping records with themselves seems so easy that they argue against centralization. Organized filing centrally will obviously entail following of rules and an end to ad-hoc modification and deleting of files. Therefore they claim a loss of flexibility.
4. Perceived loss of control: If we have the records with us, we experience a sense of power. People who want information would ask us and that gives us a feeling of importance. If I am keeping the records, my boss will have to call me for information and would be dependent on me. Agreeing to move the records to a central location would amount to giving up my rights.
5. Resisting destruction of physical records: This was another challenge that I had to contend with. Even when we had scanned documents and lodged them into the document management system, users were reluctant to destroy their old physical records. It required a lot of persuasion. Similarly, when we had converted old records into microfilms with an additional copy as a back-up, users resisted destruction of physical records. I then had to temporarily halt further conversion and wrote to the management seeking directions. Then came the diktat for destruction of records and that enabled the company give up the hired document storage-warehouses thus bringing down expenses.
Though a move towards a paperless environment is a reality, it still faces roadblocks and these need to be handled well and with certain measure of firmness. In most cases it is about instilling a discipline and bringing about an order. Once users experience the benefits of electronic handling of documents, they push for more and never look back.
If we are convinced about the usefulness of microfilming the old records, the next step will be to work out a justification and make up a case for introducing this in the organization. So let us discuss the steps that we need to go through.
Have a valid financial justification
The first step is to identify documents which can be candidates for microfilming. For example, old accounting records that are, say, more than three years old (i.e. post statutory audit or those not required for MIS purposes), can be taken up. This would include all ledgers, vouchers, and other supporting documents. Other examples would be records related to Sales Tax, Excise, or old shareholder transactions. We need to emphasize on the advantages to the users like freeing up of storage space and ease of access. In the organization that I put this system in, we could give up a storage space hired for keeping these records and we could access old records which was an uphill task earlier.
Our old documents, even if archived, reside on magnetic tapes, cartridges, low cost disks, etc.; but these are expensive and less reliable as these media deteriorate over long periods of time. Microfilms on the other hand are less expensive and have much longer life. Financial justification can therefore be easily worked out.
Organizations usually start with converting old documents in physical form as it helps in converting the bulk of documents into a single film tape / cartridge. The process is to be done carefully and it is best to outsource this activity to external agencies who are experts in this process. You have first to classify documents, number them, and then convert them in the right sequence. You can classify them on the basis of document type, year, etc. When converted, all tapes will have to be properly indexed and labeled. It is necessary to exercise control to ensure that documents are not missed out and also that they are not duplicated.
To ensure authenticity, the recording starts with a document signed by the authorized person and similarly a document at the end signals the end of recording. Such a microfilmed record therefore cannot be tampered with. These records are accepted as evidences by various statutory authorities.
In order to access and read these tapes we would have to buy a film reader which converts the tiny films into a readable form through display on a screen attached to the reader. These machines are relatively inexpensive and therefore affordable.
Say goodbye to the old habits
After having converted our old physical records on films, the next step will be to avoid creation of new documents in physical form and so that we do not go through the entire grind once again. For example many organizations have stopped printing general / sub ledgers but may take one copy at the year end. It is here that we need to bring about a change – why not transfer the ledger directly from magnetic media to microfilm tapes. The technology available today makes this possible and so it is best to use this interface. The same principle can be applied to various documents that need to be held over long periods of time.
So here is a simple technology which can be gainfully used to solve a part of our storage problems. The process may seem difficult in the beginning but after the initial conversion, the ongoing process falls into a routine and can be easily managed.
Microfilming of old records is an area which has largely been ignored by CIOs. Apart from a few companies in the banking and financial sector and some government departments, most have not made use of this technology. The decision to microfilm old documents has largely been taken by functional departments; but the CIO, in my opinion, can take a lead here and explore application of this solution in his organization.
What is Microfilming?
Microfilms are films containing micro-reproductions of documents for transmission, storage, reading, and printing. These are essentially photographs of documents and are images commonly reduced to about one twenty-fifth of the original document size.
Microfilming, also called microphotography, consists in the reduction of images to such a small size that they cannot be read without optical assistance. Such a photographic compression often results in a ninety-nine percent saving of space. With the advancement in the field of documentary reproduction, the function of this facility is not only restricted to storage but also classification, and retrieval. The usefulness of this medium is significant as many documents deteriorate over time because of the poor quality of paper and print.
Common use of microfilms
Microfilming is a widely used practice in the government as also in banks and financial institutions. The huge volume of public records in government and customer records in banks, for example, make up a good case for microfilming.
In companies, this has been used for storing several documents that are statutorily required to be kept for several years. For example, accounting records are required to be preserved for eight years by the Companies Act and the Income Tax Act. Similarly other Acts such as Central Excise Act, Sales Tax Act etc. have their own stipulations. Some companies have also used for this medium for preserving old legal files, employee personnel records, customer records etc.
Safety and security
Besides saving space, the most important feature of this medium is document integrity and information security. Preservation of rare and deteriorating documents is considered one of the most important purposes in micro-recording. Valuable rare documents are now being microfilmed to preserve them from loss and destruction. Moreover it must be protected against loss, which would be irrecoverable in the case of valuable documents, records or rare books. Several duplicates of microfilmed documents can be made available, while the original documentation may be kept in archival storage or may, in fact, be destroyed. For additional security, negatives and positives can be stored in different places; being of small bulk, it can be specially protected. The film, if properly processed it will last much longer than the originals.
Advocating its use
In my opinion, it’s time CIOs examined this solution and evaluated its use in their organizations. The advantages are substantial as by freeing up space used by these documents they can save huge rentals, the method enables quick access and retrieval and it ensures their safe keeping much better than what is possible with traditional methods with physical documents.
In my next dispatch, I will explain my experiences with the use of microfilming and the benefits we got from the usage.
We always like to complain about the lack of support from the management or non-cooperation of the end users. We say we would have gone miles, had they been kind enough to us and had helped us for the cause. The lament is justified to some extent and I agree that we, as sincere professionals, need that kind of patronage.
All projects, however, do not go wrong and neither are all situations so bad. The very reason for our great going is that we all have several successful projects to our credit and we are confident of achieving many more goals. We talk of our success stories in various forums and willingly oblige magazines when they want to publish our case studies. It is easy to corner all the credit to ourselves and claim that we succeeded in spite of several roadblocks, but will we be honest in saying that no one helped us in the entire show? In case we have not adequately recognized and acknowledged the contributions made by various wings of the organization, it can be regarded as our weakness The management does its bit to approve and sanction funds for our projects; and unless the end users make use of the systems we develop, how can we ever hope to meet the objectives? We, therefore, are never alone and we have to recognize the contribution of others in our endeavors.
It will only be fair on our part to acknowledge the support that we receive from various quarters. This way, on one hand, we can complete the loop and, on the other, encourage them to lend their support for all our future projects. It is normal for people to resist change in the initial stages but we have learnt to get over this part through our experiences. If users willingly accept the technological changes on their own, it will be proper on our part to give them the credit for doing so.
There are various ways in which we can acknowledge their support, let me write down a few:
- Once we get approval for our budget or project, we can write a note to the Board/ CEO/ others, thanking them for the approval and assuring them of our full efforts to make the project(s) successful.
- It is a good practice to send periodic reports to the management giving them an update on important projects so that they feel reassured on the projects/ budgets sanctioned by them.
- On successful completion of projects, send a ‘thank you’ note to the concerned business/ functional heads.
- Let them light a lamp or cut the ribbon whenever we kick-off or launch a project, and ask them to deliver a short address.
- If they have done a good job, cite them as examples/ reference to the rest of the organization.
- Formally thank them for their role once the project has been successfully completed.
- Take them out for a dinner or an event as recognition of their contribution and support.
- Involve them during the design of the processes, drawing a road map etc. to give them a feeling of participation.
These are some of the measures that came to my mind and I am sure you would have many more brilliant ideas. The point of emphasis is that we need the support of various stakeholders for the success of our ventures and we should get them on our side through a genuine sense of understanding and appreciation of their views and feelings.
A paperless office was a dream of many an organization in the 1980s and ’90s. The simple word processor was followed by spreadsheets and other office automation software. It was soon realized that documents so created needed to be managed. So the ‘Document Management System’ (DMS) came into being and later as the World Wide Web came along, it dawned on people that the artifacts placed on the Web also needed to be managed; so the ‘Content Management System’ (CMS) followed. Now let us look at these terms and understand them.
A document management system (DMS) is a computer system (or set of computer programs) used to track and store electronic documents, and / or images of paper documents. It is usually also capable of keeping track of the different versions created by different users (history tracking). Now, the term has some overlap with the concepts of content management systems. DMS is often viewed as a component of Enterprise Content Management (ECM) systems and related to digital asset management, document imaging, workflow systems and records management systems.
In early 2001 when I put in DMS in our organization, it took us some effort to change the organization’s work culture; I had to persuade people to try out the electronic form of managing documents. When it succeeded, I was very happy and satisfied but soon realized that I had to expand my horizon of thought to consider other demands that had suddenly sprung up. Our marketing department wanted all their publicity material, advertisements in print, radio and TV, artwork and other creative material to be stored, catalogued and made shareable. That was a tall order and I had to struggle to find a solution. Later, as our website got loaded with content and our intranet started exploding with matter, it became apparent that these too needed our attention. I then got exposed to the developing area of content management.
An enterprise content management system (ECM) involves management of content, documents, details and records related to the organizational processes of an enterprise. The purpose and result is to manage the organization’s unstructured information (content), with all its diversity of format and location. The main objectives of enterprise content management are to streamline access, eliminate bottlenecks, optimize security and maintain integrity.
A CMS/ ECM provides a collection of procedures for managing work flow in a collaborative environment. The procedures are designed to do the following:
- Allow for a large number of people to contribute to and share stored data.
- Control access to the data, based on user roles (defining which information users or user groups can view, edit, publish, etc.)
- Aid in easy storage and retrieval of data.
- Reduce repetitive duplicate input.
- Improve the ease of report writing.
- Improve communication between users.
In my last organization, I had put in ECM/ CMS and included all forms of records, including normal office documents. We provided access to all content through the enterprise portal, and ensured security by centrally defining access rights accorded by the respective managers through a work flow process. Placing all important office records centrally had quite a few advantages; data could be shared in the group, security features could be enabled and data management in terms of safety, back-up etc. became much easier. People could access records at any time and from any location since it was not confined to a desktop or laptop.
It is however important that the purpose of putting in content management system in any organization should be clear and subsequent steps should proceed in the stated direction. Success of the system can be gauged by fulfillment of the objectives, such as information sharing, safety/ security of data, user convenience, etc.
These festive months are times to enjoy and rejoice. We do have fun; but there is something else to these festivities that give us the jitters. It is the greetings messages that run unhindered through our communication pipes and create those famed bottlenecks.
As a CIO, I have faced these situations often and I may have interesting stories to tell. It was in 1998 when I had just connected all offices of my organization on e-mail. In the initial period, reluctant users would send occasional mails to others only when forced to. We had then connected all offices using VSAT network with a meager bandwidth as it was expensive. But as Diwali approached, the network went numb and it took us a while to discover that it was that sudden burst of traffic (with greetings messages) that choked our network. Then came the New Year and the network started to blink again. People had by then learnt to create new cards using paint brush and other utilities; and those attachments were really heavy. Over the next two years, we took several measures to address this problem. For instance, I sent a mail to all requesting them to be choosy when sending greetings and to be measured by sending to those whom they knew rather than marking it to all. When that didn’t work, we had to block access to central groups for all except a few seniors. In order to bring a smile to those sad faces, we introduced a greeting cards application, asking people to choose cards from them instead of creating their own. We invited all the creative artists to draw out new cards with their signatures and add to the library.
The matter changed over the years as bandwidth got cheaper. With larger pipes the problem has perhaps become manageable or perhaps not quite so, as this traffic still poses a problem often. We know of the choke created on our mobile networks when people’s SMS messages flow with gusto. The mobile companies had to resort to higher tariff for such periods as a measure for controlling traffic.
The greetings conundrum does cause its own sweet trouble. Being a social activity, it makes difficult being harsh with people, and managements generally sympathize with their brethren. This is tricky; CIOs have to find a new way to address this problem. There are few tips that I can offer, though there could be other good methods adopted by some of us.
1. Advisory to users: Users sometimes need to be educated, made aware or simply told to exercise judgment. It may help sending a message to all asking them to send greetings to only those whom they know rather than marking them to all in the organization. I also used to mention of users’ complaints of unsolicited greetings messages from people not known to them.
2. Set an example with our conduct: I decided that I will not send mass messages, and will also not reply to such messages even if they come from close friends. I then persuaded employees in my department and many senior functionaries to observe such celibacy; and it worked.
3. Create a greetings library for internal usage: This reduces traffic and helps standardizing this ritual besides reducing the data traffic. Those who do not follow this practice can be talked to.
4. Greetings coming in or going out of the organization: Such incoming and outgoing messages also create a bottleneck. Though not much can be done in respect to our dealings with official contacts, we can request users to make use of birthday greetings sites, or their personal mail (yahoo/gmail etc.) for greeting their friends and other contacts.
Festivals are social events and we have to let people enjoy and greet each other. While such freedom is desirable, it makes sense to keep a watch on the computing and network infrastructure and ensure that it is available to the organization and people at large. That is the responsibility that a CIO is bestowed with, and he has to find a way to ensure that the systems function at all times.