Discussion Locked

Company Standards Vs Technical Knowledge

0 helpful
4 replies
Closed to new repliesThis discussion is closed. It stays readable, but it takes no new replies.

How do company standards came about?
Do we need to tailor made our knowledge to the company standards?
How to use your technical knowledge to adapt to the company standards?

4 replies

by thechas

Company standards come about in various ways.

The most common these days, is the result of preparing for an ISO 9000 certification audit.

They also come about from customer audits, and a desire for standardization.

I don't know that you need to tailer your knowledge to the standards, but you do need to tailer your solutions and work habbits to the standards.

The theory behind ISO 9000 and other standadization schemes, is that if you document what you do, how to do it, and follow theprocedures, you will benefit from consistency and error reduction.

Chas

by djent

That would be the ideal method. Unfortunatly many policies are implimented via upper management and HR Dept. and have little bearing on needs, a CEO becomes incenced at some incident and issues an edict that becomes policy. Its sort of like our tax laws, this process is beauracracy at its finest.

by lordinfidel

There are alot that IT has control of.

As the guy in charge of Network Operations. It's my responsibilty to make sure that everything is documented.

If we have a procedure in place for doing something, then it needs to be written down.

This is called a SOP (for all you prior svc out there) Standard Operating Procedures.

It is a flexible document that can change as your needs/procedures change.

But that is where you need to start. Document your current procedures on how to do something. Document your Networks config (spreadsheets and IP's go hand in hand).

Documentation should be done everytime you do something new.

To give you an example; although I have built and secured well over 1000 servers, during our last co-location build out [causing us to move to a single OS platform], everything was documented from the building of the hardware to the install of the OS, to the hardening of the box.

Each step was documented. This was done for several reasons. 1- In case of a problem I can review what I did. 2- In case of my demise, someone will know what was done. 3-In case of a review, we can show what was done. 4- The documentation will serve as a blueprint for future systems that need to be added.

Let your Exec's haggle over the company dress code. Just stick with IT. If it falls into the realm of IT, make the decision, tell your immediate supervisor/exec about it if it will affect the entire company (ie e-mail size limits) and document it.

by madmark

A large part of IT is documentation. Those documents include policies, standards, baselines, guidelines & procedures. Each of these documents focuses on a specific category of information related to the design & implementation of IT components.

They feed into one another in a hierarchical order with policies being at the top, followed by standards & baselines, guidelines, then procedures forming the base of a pyramid structure.

A policy is a strategic document defining the scope of requirements for an organization. A policy discusses issues broadly using terms like goal, mission, objective & purpose. A policy should look out about five years & include visions of the future. It may also serve as proof that senior management has performed prudent due care.

The remaining tactical elements round out with due diligence.

Standards define compulsory requirements within an organization. They discuss the types of technology to be deployed, & establish uniformity across the entire environment. Standards define the steps, methods and means by which the goals of the policy are to be met.

Baselines flow directly from standards. A baseline is a specific set of requirements that all systems within an organization must meet or exceed. Often baselines are system specific. They may be imposed by industry or government standards, such as IEEE, ITSEC, or CIS Baselines.

Guidelines are operational handbooks on how standards and baselines are implemented. They offer flexibility in implementation to allow for condition specific alterations. Guidelines prescribe methodologies and suggest specific solutions for implementation.

Procedures are the detailed how-to documents that define step-by-step mechanisms from the upper tier documents. Most procedures are platform, OS, and software specific.

Hope this helps!

This discussion is closed to new replies.