By Douglas W. Frye
235 pages | PDF | 9.191 KB | Download | Password: network
Technology is progressing at an astounding pace, and many organizations are working so hard to implement the technologies they need to survive need to understand how their network security policies and procedures regimen fits into the picture.
Technical workers and management tend to have one thing in common: they don’t appreciate the constraints the other works within when going about their jobs. Management criticizes the system administrators for not understanding how the best technical solution isn’t appropriate for meeting the company’s goals, while the system administrators criticize management for not understanding that what they’re asking for is impossible, overly expensive or foolhardy. While some counter-examples do exist in the IT world, quite often those in charge of running a business or governmental organization are professional managers rather than professional technologists with managerial training. Most of the time, those charged with constructing and implementing the technical architecture do not understand the business environment in which their organization is operating. After all, their job is to simply build what they’re told to build, so what difference does it make if they understand the business context or not?.
Over the past few decades, the ability to communicate with others electronically has advanced dramatically, leading to first the creation of the Internet and later the World Wide Web. The impact of this phenomenon on organizations concerning the pace of operations and the need for efficiency in their business processes is significant and will only become more so for the foreseeable future.
Originally a project of the U.S. Department of Defense (DoD) Advanced Research Projects Agency (ARPA), its task was to give various DoD activities the ability to share information through networked computers, hence eliminating the need to wait for surface mail to be delivered. As the cost of both computers (also originally developed by the U.S. Government) and connectivity decreased, private industry’s ability to implement information technology grew.
Before IT evolved to the point at which geographically distant parties became able to communicate with each other in beyond talking to each other or faxing each other, the only way to gather information was from the individuals responsible for their particular functionality. These “stovepipes”, established based on how labour was divided at the time, were only concerned with their specific requirements and had little or no regard as to how their processes related to those of other parts of the organization.
A major implication of a process-centric approach to information technology implementation is that an organization will be forced to change its emphasis on how it rewards its employees from doing one’s job in isolation to helping to enable the business process or processes in which they reside. In the public sector especially, it is extremely difficult to realize organizational change. Instead, the organization goes through great pains to maintain the status quo. Many in government remember the days when new systems were custom-built and implemented functionality as specifically defined by the procuring organization’s requirements. ERP systems, on the other hand, establish its options on already-coded best business practices and forces the organization to choose among available options, with “downstream” choices constrained by those made “upstream”.
Manufacturing and Production workers are what most people see in their minds when they are asked to picture a company employee, at least traditionally. These are the men and women who, for example, work the assembly line in an automobile plant. In the IT or “information worker” industries, they are the people who write the code or compose the documents that comprise the organization’s products. Factory workers are the epitome of what was once the predominant economic model for an organization: tasks separated out to an extent that sometimes the individual worker did not know how what they did on a daily basis fit into the overall picture of the organization’s mission. Because production workers mostly worked on a quota system, and were rewarded or punished based on whether or not they met the company’s expectations, they had no reason to care how what they did contributed to the organization.
In today’s age of the information worker, the business or production process they are within is critical knowledge. Despite their increased reliance on an IT system’s output, factory workers typically have only one job to do at a time and that job has been integrated into the overall business process by someone else; it’s not the line employee’s job to think about it. For the information worker, however, it is imperative that they realize how what they do impacts the rest of the process.
For the expensive machinery, operations must, for example, know when to take it offline for maintenance. To determine the maintenance schedule, operations must know from the production schedule when the best time to do so would be. If there is no “best time,” the production planning system must be notified of when the system will be taken offline in order to allow the systems customers, customer service and sales access to be updated with accurate availability status and dates. If all this is accomplished automatically, it is seamless. If not, it is a potentially long process of manually accessing and updating several different systems, which leads to input errors and incomplete updates, meaning that the data in one system is different than the data in another system, which is disastrous. Instead, it is always preferable to rely on an “authoritative source” for each piece of data throughout the enterprise to ensure consistency (and assuming the single source is correct, of course).