Jumat, 21 Oktober 2016
Pohon duit
Rabu, 19 Oktober 2016
Pohon duit
Rabu, 05 Oktober 2016
History ISO 20000
I was interested in the origins of ITIL and ISO 20000, and began looking it up on the internet and in literature. There are bits and pieces of info here and there, rumors and info of questionable quality on forums and blogs. I have managed to collect this information and put it in a table in an organized fashion for the convenience of anyone who might share the interest.
Since some of the sources are not 100% verified, please feel free to comment if you have an update or complementary info.
Some myths (Falkland war origins of ITIL) are funny and believable, but denied by the authors.
The role of IBM and its Information Systems Management Architecture (ISMA) is pretty vague; even the stakeholders from that time do not agree on the degree to which it influenced ITIL. I am ready to believe that ISMA played a significant role in the forming of ITIL V1, but that vehicle quickly took the road and went many miles from its origins.
ITIL_timeline
The late Margaret Thatcher was first elected Prime Minister in 1979. The fact was that the UK Government’s IT budget was extremely large and difficult to control, and it is quite reasonable to think that ITIL development was related to cost-cutting, efficiency-driven policy of that time.
As for ISO 20000, information on its history is even scarcer. I thought it would be fun to see major milestones and deliverables side by side in a single table:
ITILISO/IEC20000
1986CCTA (UK Government’s Central Computer and Telecommunications Agency) authorized a program to develop a common set of operational guidance with the objective of increasing efficiencies in Government IT.
1988GITMM – Government Infrastructure Management Method was formalized and issued as guidelines for Government IT operations in the UK focused on Service Level Management. Also in 1988, the development team was expanded and work continued on Cost, Capacity, and Availability.
1989GITMM title proved inadequate. It is not a method, and the “G” was making it unmarketable outside of government. Finally, it received a new name: IT Infrastructure Library – ITIL.
1989First ITIL book published, Service Level Management, Help Desk (incorporating the basic concepts of Incident Management), Contingency Planning, and Change Management.
1990Problem Management, Configuration Management and Cost Management for IT Services published.
1991Software Control & Distribution published.
CCTA initiated IT Infrastructure Management Forum as a formal user group.
1992Availability Management published by CCTA.
1993Examination Institute for Information Science (EXIN) established in Netherlands to deliver and administer the ITIL examination.
1995British Standard Institution (BSI) published the first version of DISC PD 0005:1995 – Code of Practice for IT Service Management. It described four basic ITSM processes.
1996(July) First ITIL Service Manager class delivered in United States by US company, ITSMI.
1997Customer-focused update to the Service Level Management book.
1997ITIMF legally becomes what we know today as the IT Service Management Forum (itSMF UK).
1998BSI publishes a revised version of DISC PD 0005:1998 and it already described all five process areas and 13 processes as we know them today.
2000Service Support V2 publishedPublished BS 15000:2000 – Specification for IT Service Management, which was used together with the code of practice DISC PD 0005.
The third supplementary document DISC PD 0015:2000 IT Service Management Self-Assessment Workbook was published. It was a questionnaire used to make an assessment of compliance degree with BS 15000.
2001Service Delivery V2 published.
CCTA became a part of the Office of Government Commerce (OGC).
Microsoft released the Microsoft Operational Framework (MOF) based on ITIL.
2002Application Management, Planning to Implement IT Service Management and ICT Infrastructure Management published.Some revisions and rewriting followed, resulting in standard documents very similar to today’s norm:
BS 15000-1:2002 IT service management – Specification for Service Management;
PD 0015:2002 – Self-Assessment Workbook
2003Software Asset Management published.
British Computer Society’s ISEB starts ITIL Practitioner trainings and examinations.BS 15000-2:2003 IT service management – Code of Practice for Service Management published.
PD 0005:2003 Guide to Management of IT Service Management published with explanations of the purpose of BS 15000, and also the framework guidance on how to use the standard processes and implement them.
2004Business Perspective: The IS View on Delivering Services to the Business published.BS 15000 was adopted by many service companies in UK, and countries worldwide accepted it.
2005BS 15000 was placed on the “fast track” by the ISO. By the end of the year, with some moderate changes, it was published as ISO/IEC 20000 standard:
ISO/IEC 20000-1:2005 Specification is very formal, it defines processes and provides assessment/ audit criteria.
ISO/IEC 20000-2:2005 Code of Practice with HOW-TOs and best practices for implementation of Part 1.
2006(June) ITIL Glossary V2 published
APM Group Limited announced as preferred bidder of ITIL accreditation & certification program, over the itSMF International, which was expected to win.
2007(May) ITIL V3 five core books published.
2009ISO/IEC TR 20000-3:2009 Guidance on scope definition and applicability published.
2010Peoplecert Group, the new ITIL Examination, Institute accredited.ISO/IEC TR 20000-4:2010 Process reference model – describes the service management system processes implied by ISO/IEC 20000-1 at an abstract level.
ISO/IEC TR 20000-5:2010 Exemplar implementation plan for ISO/IEC 20000 -1 – provided guidance to implementation of ISO/IEC 20000 by example and advice.
2011(July) ITIL 2011 update published.(April) ISO/IEC 20000-1:2011 – new version of specification is out.
2012(February) ISO/IEC 20000-2:2012 – new Guidance on the application of service management systems published.
NowWork in progress: ISO/IEC 20000-7: Application of ISO/IEC 20000-1 to the cloud. ISO/IEC 20000-10: Concepts and terminology for ISO/IEC 20000-1. ISO/IEC 20000-11: Guidance on the relationship between ISO/IEC 20000-1 and related frameworks.
To better understand ISO 20000, you can also find Service Management System-Related documents as a free preview
ISO 20000 KNOWLEDGE BASE
may bring a structured, easy-to-understand and easy-to-implement framework, but it also uses clearly defined terminology that enables ITIL experts around the world to understand each other. As in any other field of interest, ITIL terminology also uses terms that may differ from their usual meanings in the English language, while others may be self explanatory.
Within this article, some common, and important, ITIL terms will be explained.
Service
What better way to start with ITIL terminology, than with an explanation of service. Service is anything that you have to do, in order to make deliverables valuable to the customer. For example, e-mail as a service is what customers will use to exchange messages, files, documents, etc. However, the customer will not be aware of, or interested in, the technology behind it, or how it’s set up, as long as it can be used reliably – it’s considered valuable. You can read more about IT Service Management here.
Service Catalog and Service Portfolio
Often, there is confusion between Service Catalogue and Service Portfolio, as both contain lists of services and corresponding SLAs. However, while Service Catalogue contains only a list of active services that are available to the customers, Service Portfolio contains a list of all services: active, active but not available (e.g. legacy systems that are still used by few end users), services in development or planning, and services that have been shut down.
Service Level Agreement (SLA) and Operational Level Agreement (OLA)
Service Level Agreement is document signed between customer and service provider in which service and guaranteed levels of service delivery are described. For example, a SLA would include the time frame in which service will be available, metrics that will be measured in order to provide the expected level of service, etc. Operational Level Agreement, on the other hand, is an agreement between organizational teams that are included in service delivery. There might be several teams involved in service delivery (server, networking, application…), which all must work together in order to meet the requirements stated in the SLA.
Utility and Warranty
Utility and Warranty are like two sides of the same coin, and without them service has no meaning. Utility is commonly referred to as “fit for purpose,” and Warranty as “fit for use.” You can imagine Utility as a service’s ability to do what it was built to do (e.g. an e-mail service must be able to send and receive e-mails). Warranty, on the other hand, is a service’s ability to be usable by the customer in the expected and agreed way. For example, if you have an e-mail service that is used for sending and receiving e-mails (Utility), but it can’t handle more than two concurrent emails, or every 100th email gets lost, than that service’s Warranty is failing.
Incident, Problem and Known Error
An Incident is an event that caused degradation or disruption of a service (e.g. e-mail is not working). Read more about ITIL Incident Management.
A Problem, on the other hand, is the root cause of the incident, or many incidents that repeat with the same root cause (e.g. e-mail is not working, file sharing is not working, users can’t print, all due to a network outage – all at the same time, generating lots of related incidents). A good example of the difference between ITIL’s definitions of Incident and Problem are the famous words from Apollo 13: “Houston, we have a problem.” However, according to ITIL, the correct terminology would be “Houston, we have an incident.”
A Known Error is an incident or a problem whose root cause has been identified and some sort of Workaround has been implemented. It will remain a known error until change is applied that will correct the root cause permanently, and then it is referred to as a Solution.
Service Desk
Service Desk is a single point of contact between end users and service provider. It’s used to receive and resolve incidents, service requests, requests for information, and to communicate and coordinate communication, between service provider and end users (customers). However, people commonly think of Call Center, Help Desk and Service Desk as synonyms, which is not the case – as a Call Center doesn’t attempt to solve incidents, and a Help Desk doesn’t handle service requests. More information about Service Desk is available on this blog post: Service Desk: Single point of contact.
Service Request
Service Request is another ITIL term, which is used for requests for new services or alteration of existing ones. For example, an end user may ask for internet access (new service), or increase of mailbox size (alteration). In general, Request For Information is considered to be part of Service Request, and so is Request For Change.
Request for Change
Change Management is an important part of ITIL and IT Service Management in general; therefore, any change needs to start with a formal and detailed request to make the change – Request for Change (RFC). The RFC has to include a description of the change, whether there is a business need behind it, components / services that will be affected, cost estimates, risk assessment, and approval status. Get more information about ITIL V3 Change Management – at the heart of Service Management.
An example would be installation of a new application server that is required by the finance department. According to ITIL best practice, you can’t just go and purchase a new server, install some software and attach it to the corporate network. There might be not enough room in the data center racks, or not enough power supply or cooling, or there might be an unused server already available. These and numerous other reasons must be considered before implementing, but most important is that there is clear trail in the form of formal requests that will then start the change process.
Selasa, 04 Oktober 2016
12 Step implementasi ISO 20000
If you dig into the content of ISO 20000-1 (requirements for the Service Management System, i.e., SMS), questions will start to pop up. And, maybe one of the most interesting ones is certainly “How to implement all this?” Well, although it sounds complex, if you approach your implementation systematically, it shouldn’t be too complex.
In this article, I’ll explain the workflow of the ISO 20000 implementation. By making the decision to implement the standard’s requirements, you already took the first significant steps. If you would like to learn more about the main reasons why companies don’t implement ISO 20000, read the article What are the most common ISO 20000 implementation myths?
The implementation steps
blogpost-banner-20000-consultants-en
What I‘d suggest for you to do is – be systematic. This means that you should avoid ad-hoc solutions, i.e., decisions. If you change implementation direction too often, that will create chaos. Here are 12 implementation steps set in logical order:
Obtain management support – That’s your first battle, to convince your management to support the implementation. Why? They need to allow funds and, besides money, you need a strong sponsor. That should be your management.
Establish the project – That’s not a mandatory step, but it will significantly increase the efficiency of the implementation. That’s because you have a clear goal, people (and other resources), a time plan, inputs, outputs … etc. Project Management is your tool (being responsible for the implementation) to keep things under control and achieve the desired results (implementation of the SMS and certification against ISO 20000-1).
Perform assessment and gap analysis – This is one more step that is not mandatory. But, it’s highly advisable to perform a gap analysis and check your existing management system against ISO 20000 requirements. I’m pretty sure you are managing incidents or changes even without ISO 20000 in place. So, check what’s missing to comply with the standard and you will not have to do those things once again (and, not to forget – you will shorten implementation time and save resources – monetary as well as non-monetary ones).
Define scope, management intention, responsibilities – This is the phase when you need to set the foundations of your SMS and define the direction of all further activities. So, in this step you will define the scope and policy of the SMS. Read the article How to define the scope of the SMS in ISO 20000 to learn more about the scope of the SMS.
Implement support procedures – These are “non-productive” procedures, i.e., the ones that are not involved in daily operations of your SMS, but they have an indirect effect on them. These are, e.g., Procedure for document and record control, Internal audit procedure and checklist, Communication procedure … etc.
Generate process / function documentation – Now, the “party” starts. The previous steps were used to set up the management system. Now, you have to add all the processes required by the standard. You will use previous experience, i.e., knowledge you have, external help, tools, etc. for the implementation. If you decided to use the project approach, this is where it will be most beneficial.
Implement processes and/or functions – This is the same as with the previous bullets. This is the time when theory goes into practice. Additionally to (hopefully) well-prepared process documentation, your managerial skills will come to the surface.
Perform training and awareness programs – It’s important that all people involved in the SMS are aware of their tasks, and that they have the same understanding (about the purpose, i.e., goals and processes) of the SMS and “speak the same language” (e.g., when a user reports malfunctioning in some of the services – it’s an incident).
Operate the SMS – As I already mentioned, your (or the person who is the SMS manager) managerial skills are important not only during the implementation, but also afterwards. Remember, once you implement the SMS, it will support IT services used by your customers. And that can be tricky. So, you have to be good at managing those services, i.e., running the SMS.
Create the Continual Service Improvement concept – Besides the fact that it’s one of the requirements, it’s also one of the facts in everyone’s’ (including the SMS) life – changes are continual. And, that’s a good thing. It will improve the performance of the SMS and make customers happy.
Implement the Continual Service Improvement concept – Once you define your continual service improvement concept – implement it. And, keep it running even if you have to improve it (from time to time).
Conduct the internal audit – This step will tell you how well you have done so far. Find someone objective (who was not part of the implementation) to perform the audit.
Management review – this is one of the mandatory steps and your conclusion of the implementation project. And, as much as I experienced, your management would like to know what’s going on. Make good preparation (you have many requirements in the standard, and that will help you successfully prepare for the meeting).
And, that’s it. You are done. What is left are audits:
Stage 1 certification audit (Documentation review) – Before the certification audit, your certification body will visit you and check the SMS. This is your chance for an open talk where you can only gain. They will tell you what they think about your work, i.e., what you need to improve.
Stage 2 certification audit (Main audit) – This is your “big moment.” Auditor(s) will visit you and tell you that everything is perfect, isn’t it? I hope so. Anyway, this step is your final step and I hope it will verify your successfully implemented SMS.
Is that all?
More or less – yes. There could be some smaller deviations, but in essence, the above-mentioned steps will bring you to finish the implementation. You may have noticed that the first set of steps were SMS set-up related. Then came processes and functions definition and implementation. Although management confirms the desired results, continual improvement is your “destiny.” It never stops, on the contrary – it should ensure you are getting better day by day.
Use this free Diagram of ISO 20000-1:2011 implementation process to manage your ISO 20000 implementation
Matematic
The internet had lots of great and terrible uses of math and mathematical visualizations in September 2016! This is our opportunity to applaud the winners and be confused by the blunders. Here are a few of my favorites:
1. The Gold Star goes too...
Henry Segerman for his amazing 3D mobius transformation henry_segerman_terdragon_smallartwork. In particular, I want to call out his Stereographic projections. A Stereographic projection is a mapping (that is, a function) that projects a sphere onto a plane. In the case of Segerman's art, you can shine a light from above to make the projection appear.
screen-shot-2016-10-04-at-5-49-03-am
Stereographic projections have a strong and beautiful connection to moebius transformations. Moebius (or Möbius, like the Moebius band!) transformations have a key part to play in understanding complex analysis. In particular, they encompass a particular type of mappings (functions) that map the complex plane back onto itself. Stereographic projections have the power to make something really complicated appear relatively simple. To really understand why stereographic projections are so meaningful, I recommend the "Moebius Transformations Revealed" by University of Minnesota professor, John Rogness. I promise that there are almost no equations and you'll probably learn something:
Do you need one of these in your life?
2. Terrible Use of "Mathiness"
My least favorite mathematical graphic from September has to be the Bloomberg BusinessWeek's visualization on income. Income is a really important topic. And the idea that "everybody thinks they're middle class" is an important piece of the puzzle to understanding why income inequality is growing over time. However, I strongly disagree with the way they presented the material.
First, let's take a moment to wonder at the title: "Everybody thinks they're middle class." The visualization gives only 5 individual's opinions, and yet we presume to call this a representation of "everyone"? In high school I learned that three points make a line... but hopefully we all realize that a 5 person sample out of more than 300 million Americans does not a statistical sample make! And since, with a sample size of 5, it's not providing scientific insights, then I'm left to believe that it's goal has to be emotional insights to the nontechnical audience... which is also does poorly.
How well does it communicate with a nontechnical audience member? The article is basically one big visualization with a little bit of text:
bloomberg_middle_class This is a visualization showing the annual income of Americans. Annual income is on the x-axis against the percentage of the population who have that income level on the y-axis. How to read it? Well, one can learn that approximately 10% of the population makes $30k and about 4% of the population make $100. Basically, this visualization is like a histogram with a million little rectangles... drawn as a continuous line. However, it obfuscates what percentage of the total population are above and below each data point.
Our society has been very focused on the top 1%. So, when I look at this graphic, I want to understand where in this visualization the top 1% is. I'm also curious about other things, like: what is the mean income of this study? It's really hard to tell when you look at the Bloomberg graphic. What I really want is something more like a Pareto chart or a cumulative distribution curve:
Here we get the histogram AND information about the cumulative values. So I can visually see when I've reached 50%, 80%, or 98% of my population sample by reading the right y-axis. Ultimately I think the Bloomberg visualization falls short of providing insights to anyone in both content and visualization. Better luck next time, Bloomberg!
3. Math Graphic of the Month
I'm guessing that if you are reading this website, you probably believe in math and science. Thus, I think you will also appreciate that science (and math!) do not have political agendas. Simply put, mathematics is a tool to learn about and communicate the facts of the world. In our social climate, I think it's important to remember that there is a division between science and state. They have different goals and different aims. And math, if math had opinions and emotions (which is doesn't!)... anyways, if it did, Math couldn't care less about which way you vote. In short, I think this is a beautiful reminder:
You can buy yours here.
Did you have a favorite experience with math on the internet in September? Share it in the comments below! Until next time, have a mathy October!
Sabtu, 01 Oktober 2016
Religion of technology
I walked into my bank a few days ago and found that the lobby had a different look. The space had been rearranged to highlight a new addition: an automated teller. While I was being helped, I overheard an exchange between a customer in line behind me and a bank worker whose new role appeared to be determining whether customers could be served by the automated teller and directing them in that direction.
She was upbeat about the automated teller and how it would speed things up for customers. The young man talking with her posed a question that occurred to me as I listened but that I'm not sure I would have had the temerity to raise: "Aren't you afraid that pretty soon they're not going to need you guys anymore?"
The bank employee was entirely unperturbed, or at least she pretended to be. "No, I'm not worried about that," she said. "I know they're going to keep us around."
I hope they do, but I don't share her optimism. I was reminded of passage from Neil Postman's Technopoly: The Surrender of Culture to Technology. Writing in the early '90s about the impact of television on education, Postman commented on teachers who enthusiastically embraced the transformations wrought by television. Believing the modern school system, and thus the teacher's career, to be the product of print culture, Postman wrote,
[...] surely, there is something perverse about schoolteachers' being enthusiastic about what is happening. Such enthusiasm always calls to my mind an image of some turn-of-the-century blacksmith who not only sings the praises of the automobile but also believes that his business will be enhanced by it. We know now that his business was not enhanced by it; it was rendered obsolete by it, as perhaps the clearheaded blacksmiths knew. What could they have done? Weep, if nothing else.
We might find it in us to weep, too, or at least acknowledge the losses, even when the gains are real and important, which they are not always. Perhaps we might also refuse a degree of personal convenience from time to time, or every time if we find it in us to do so, in order to embody principles that might at least, if nothing else, demonstrate a degree of solidarity with those who will not be the winners in the emerging digital economy.
Postman believed that computer technology created a similar situation to that of the blacksmiths, "for here too we have winners and losers."
“There can be no disputing that the computer has increased the power of large-scale organizations like the armed forces, or airline companies or banks or tax-collecting agencies. And it is equally clear that the computer is now indispensable to high-level researchers in physics and other natural sciences. But to what extend has computer technology been an advantage to the masses of people? To steelworkers, vegetable-store owners, teachers, garage mechanics, musicians, bricklayers, dentists, and most of the rest into whose lives the computer now intrudes? Their private matters have been made more accessible to powerful institutions. They are more easily tracked and controlled; are subjected to more examinations; are increasingly mystified by the decisions made about them; are often reduced to mere numerical objects. They are inundated by junk mail. They are easy targets for advertising agencies .... In a word, almost nothing that they need happens to the losers. Which is why they are the losers.
It is to be expected that the winners will encourage the losers to be enthusiastic about computer technology. That is the way of winners ... They also tell them that their lives will be conducted more efficiently. But discreetly they neglect to say from whose point of view the efficiency is warranted or what might be its costs."
The religion of technology is a secular faith, and as such it should, at least, have the decency of striking a tragic note.