Resource Library

Once an organization has categorized suppliers, one of the benefits that is quickly realized is an understanding of how supplier changes affect the buying organization and vice-versa. Changes are the modification, addition, or removal of something from the environment. The scope and scale of each change can be different. Change management covers everything from regular, low-risk, operational modifications all the way to significant organizational strategic shifts.

Organizations that plan for and conduct supplier management according to defined processes and boundaries are more likely to receive predictable, high-quality goods and services from their suppliers in a timely manner.

Regardless of your vendor preference or your experience on the Juniper JUNOS CLI, assuming you have a point of reference to another vendor, your first thought when experiencing JUNOS is, “I have been here before.” The CLI is familiar, convenient, and polished. The similarities between JUNOS CLI and another CLI such as Cisco’s IOS are not what I want to focus on here however; it is their differences I want to focus on. But first, when you connect to a JUNOS powered device and access Operational Mode (see Brad Wilson’s blog post Introduction to Juniper Junos), it looks very much like the User EXEC Mode in IOS. In fact, there are a lot of JUNOS commands that are very much like the IOS User EXEC Mode commands.

Lessons learned is a theory, or conclusion, based on evidence at a given time and describes what went wrong (as well as what went right) throughout the lifecycle of a project. Although it’s completed during the project closeout process, it should occur during the entire project lifecycle to ensure all information is captured and documented. Consequences of not having a project review of lessons learned are the increased likelihood of repeating actions that might have caused:

Previously I discussed service providers and their risks in the example of my involvement with a landscaping company. ITIL clearly states that services, “…deliver value to customers by facilitating outcomes customers want to achieve…” However, sometimes organizations and people focus on outputs as opposed to outcomes, which sacrifices some of the value of the service. This leads to a question, what is the difference between an outcome and an output?

None of us have much time to waste, so what can you do when your environment changes quickly and you need to come up to speed on a device that you have never seen before? You find the quickest way to bring yourself up to speed. Some of you will have experience with other vendors’ equipment, and some of you will not have much experience at all; therefore, we will focus on topics that will get your feet wet the quickest and have you talking Junos in no time.

What's the correct sequence of activities for handling an incident? Find out why categorization occurs before initial diagnosis in the ITIL incident management process flow so you can answer this common ITIL Foundation exam question.

As long as I've been involved in service management, one of the perennial debates that's really never been resolved focuses around how many discrete processes ITIL describes. No such single list exists in the ITIL core books. However, section 4.1 of each of the ITIL 2011 core books shows the processes described within that specific book. When we deliver accredited ITIL training, if it is describe in section 4.1 of any of the ITIL core books, then it is considered a "process".