A.I. & Learning Theory

A.I. & Learning Theory

This is where I'll keep my list on A.I. and Learning Theory :-)

http://hunch.net/

http://see.stanford.edu/see/courseinfo.aspx?coll=348ca38a-3a6d-4052-937d-cb017338d7b1

http://www.idsia.ch/~juergen/unilearn.html

What it takes to be SMART!

What it takes to be SMART!

I challenge anyone to find and add more appropriate words to the SMART acronym! Personally I quite like smart as it seems almost applicable anywhere, e.g.

- Agreements
- Contracts
- Project management plans
- Strategic business plans
- Law
- Procedures
- Work instructions
- Role descriptions
- Research
- Holiday trips

S:

Specific
Significant

M:

Measurable
Monitor-able
Manageable

A:

Agreed
Achievable
Attainable
Aligned
Acceptable
Accountable
Adaptable (of course under the correct change management process)
Audience (written or constructed for the right type of audience)
Applicable
Assignable

R:

Realistic
Relevant
Respectful
Responsible
Reviewable

T:

Timely
Transparent
Truthful

Mmmmm....

And what about:

Balanced
Extensible

Again, this is a short article and I hope that with your feedback we can add some more detail to it.

Nanoo... Nanoo...

IsleBeeBach

ISO/IEC 20000-1:2011: Waste of money or good to go?

ISO/IEC 20000-1:2011: Waste of money or good to go?

Okay, so I just paid CHF 112 for a 36 page document - surely it must be worth its value in gold.

Note: CHF 112 divided by 36 pages = CHF 3.11 per page :-) (I was hoping for PI "3.14", but wasn't that lucky!)

Let's dissect the document:

Pages i-ii contain a title page and a copyright statement. That's CHF 6.22 wasted.

Pages iii-iv are a table of contents. There goes another CHF 6.22.

Pages v-vi are a foreword - basically some gibberish and nothing really exciting. Uhm... I start to detect a CHF 6.22 trend here.

Pages vii-viii contain the introduction and is basically telling us that Deming's PDCA cycle is a really, really smart idea. Okay, so they need 2 pages for this (CHF 6.22) and I can do it in one short sentence:

"Deming's PDCA cycle really rocks big time!"

So far, I've wasted roughly CHF 30 and am none the wiser.

Oops, no wait!

Page 34 is a bibliography, sort of semi useful, but I don't really want to buy all these other standards (well, at least, not yet). It actually lists 20 other ISO standards, so better take a holiday if you intend to read them all. A very long holiday that is!

The last 2 pages (35-36) are completely blank! That's definitely CHF 6.22 down the drain. Ah well, it's good for the Swiss economy, so who cares! I certainly don't, as I'm half Swiss myself!

Okay, so once you've flicked your way past the first 8 pages, the fun really starts. Now, before we look at some of the finer details, let's sketch the big picture first.

This document has nine key sections and these together explain Part 1: Service Management System Requirements. Don't start looking for Part 2 in this document, because that's another standard known as the code of practice. Part 1 is all about what you SHALL do, part 2 (again, not this document) is all about what you SHOULD do.

Note: SMS = Service Management System

The nine sections are:

1. Scope: Who is it for, how do we use it?

2. Normative references: It roughly states: "Also read ISO/IEC 20000: Part 2".

3. Terms and definitions: It's about providing a common language and common terminology.

4. SMS General requirements: It's all about Deming's planning activities and what you need to be doing in order to get some Service Management in place. You know, the commitment, funding and policies type of stuff.

5. Design and transition of new or changed services: Okay, we can't just rush into doing things, but need to properly plan our changes.

6. Service delivery processes: Service Level Management, Service Reporting, Service Continuity and Availability Management, Budgeting and Accounting for Services, Capacity Management, and Information Security Management.

7. Relationship processes: Business Relationship Management, and Supplier Management.

8. Resolution processes: Incident and Service Request Management, and Problem Management.

9. Control processes: Configuration Management, Change Management, Release and Deployment Management.

Except a few minor changes (e.g. adding Service Request Management to a title) the standard still seems predominantly aligned with ITIL v2, and overall not much, and that's an understatement, has changed if we compare the standard to the ISO/IEC 20000-1:2005.

Alignment with other key IT Service Management Frameworks like MOF or CobiT still seem a far and distant reality, which seems weird considering the fact that both MOF and CobiT have been catching up with ITIL really, really fast, and personally I see more value in CobiT (ISACA) than I currently see coming from ITIL or ISO.

Ah well, I guess we'll just have to wait and see how the industry reacts to the new ISO/IEC 20000-1:2011 standard (which consists of about approximately 50% (19/36 pages) somewhat useful information), but personally I think it's a bit disappointing as so many other IT related subject areas could have been covered in the standard by now.

Signing off,

Nanoo... Nanoo...

PM: PMBOK, PRINCE2, Agile and Scrum

PM: PMBOK, PRINCE2, Agile and Scrum

BRM: Business Research Methods

BRM: Business Research Methods

I'll be using this blog to document my summary of the Business Research Methods subject.

Well - that's been postponed until next year for now :-(

ITSM: Articles, Literature and Websites

ITSM: Articles, Literature and Websites

I'll use this blog to list any interesting articles, literature and websites I come across.

ITIL: Incident versus Problem Management

ITIL: Incident versus Problem Management

I've noticed that although ITIL has been around for more than 20 years, there's still a lot of confusion about what Incident Management is all about and how it differs from Problem Management.

I hope that the following list, which I'll keep adding to, will help you to understand and if necessary "sell" these differences. Given more time I'll start categorizing them under People, Processes, Products, and Partners (or feel free to do this for me).

Feel free to dispute any item on this list, and also feel welcome to send me more recommendations to be added to this list. It's only a start and I won't rest until I've found at least 100 differences between these two processes!

Incident Management	Problem Management
Mainly reactive	Mainly proactive
Strong focus towards business and user community	Strong focus towards IT and technology experts
Uses the Known Error Database (KEDB)	Populates the Known Error Database (KEDB)
Restores services as quickly as possible	Less emphasis on speed, more emphasis on finding real solutions
Not responsible for creating known error records	Responsible for creating known error records
Predominantly applies temporary fixes, also known as workarounds or band-aid fixes	Is all about finding more structural permanent solutions
Typically deals with single individual incidents	Performs analysis on large volumes of incidents to detect trends and/or patterns
Applies a high level of people language	Applies a high level of technical language
Has a strong relationship with SLAs	Has a strong relationship with OLAs and contracts
Processes reoccurring incidents	Eliminates reoccurring incidents
Frequency and impact of related incidents typically not taken into account when prioritizing a (new) incident	Frequency and impact of related incidents typically taken into account when prioritizing a (new) problem
Users are able to generate incidents	Users are not able to generate problems
Increases support costs due to the repetitive nature of resolving repetitive incidents without providing a structural long-term solution	Reduces support costs with resolving repetitive incidents in a structural long-term manner
incident records may be the same	problem records should be unique
The focus is short-term	The focus is long-term
Escalates incidents to other teams (still part of the incident management process) to ensure timely service restoration	Submits change requests into the change management process with proposed solutions that eliminate known errors
Does not influence the number of incidents that are reported by users	Does influence the number of incidents that are reported by users
Investigation and diagnosis are often performed in parallel	Investigation and diagnosis are often performed sequentially
An incident can be closed although it may be unclear what has caused it (the so called root cause is often unknown)	Problems cannot be closed without a clear understanding of its root cause
Major incident reviews are not mentioned as part of ITIL's incident management process flow (incident model)	Major problem reviews are mentioned as part of ITIL's problem management process flow (problem model)
Many incidents may be linked to the same problem	Many problems are typically not linked to the same incident
Not responsible for maintenance of the Known Error Database (KEDB)	Responsible for maintenance of the Known Error Database (KEDB)
Doesn't improve the overall stability of the IT infrastructure	Does improve the overall stability of the IT infrastructure
Able to boost user satisfaction short-term	Able to boost user satisfaction long-term
Process members often "static"	Process members often "dynamic"
Most effort comes from lower (and typically cheaper) level support teams	Most effort comes from higher (and typically more expensive) support teams
Incident resolution techniques are more repetitive across incidents	Problem resolution techniques are more unique for each problem
Often includes full-time roles	Often includes part-time roles
Often performed with use of internal resources	Often performed with the support of external resources
Predominantly operates at a user level	Predominantly operates at an enterprise level
Has access to many effective commercial of the shelves (COTS) incident management systems	Has access to fewer effective commercial of the shelves (COTS) problem management systems