Posts tonen met het label Lean Six Sigma. Alle posts tonen
Posts tonen met het label Lean Six Sigma. Alle posts tonen

zondag 21 februari 2016

Lean

Introduction

I'm a fan of Lean Six Sigma. The pragmatic toolbox of Lean and Six Sigma has all kinds of tools and helpful aids to improve processes. In the past I have learned tools like Ishikawa (fishbone diagram), 5 times why, and Value Stream Mapping.

The helpful tools of LSS can help your project or department to gain more efficiency, to be more effective and to have more fun. With the tooling you can iteratively improve your way of work. And it doesn't need much time to do it. Just ask your team members every week their biggest irritation and improve this in a PDCA or DMAIC cyclus. Another great tool is to improve the visibility and communication in your team with a Kanban board.

Many of the things you learn, you can adopt this in your daily work and personal life. The way of thinking helps you improve processes or your daily life. Looking at my desk I could adopt the 5S method for sure ;-)

History

Lean started when processes became more common, for instance when Henry Ford started to build T - Fords. As soon as a process involved you can improve the process by making (small) adjustments to the process. Off course, Toyota is the example of Lean implementation in a automobile factory, called Toyota Production System (TPS), but it were the Americans that helped the Japanese build up the industry after World War II. Deming was the person that showed that you can increase quality with lower costs, by reducing wastes and more. The PDCA cyclus embodies the continuous improvement. See here for information.

Lean basics

There are 5 dimensions to support improvement in Lean : customer, process, organization, performance and behavior & attitude. There is nothing to add value when there is no customer. Customers wants products and services to add value to his or her work or life. There is also a process that you want to improve and bring it under control with people, materials and the talents of people. It's also needed to shape the organisation in order to maximize the value. And, how do we need to measure this? There are steps that improves the overall performance and there steps that brings down performance and you want to know this.





The goal is to optimize adding value (value add) to the activities instead of non value tasks (non-value add). Examples of value adding work are building a data warehouse or an analysis. Examples of non value adding activities are doing more than needed or rework. There are also activities that are needed but do not add value to activities, but it needs to be done (necessary non-value add), for instance testing.

Lean is a continuous improvement approach and focuses on design and improvement of the process. ITIL also talks about continuous improvement but does not give you the toolbox how to improve the process. Lean will you give you tooling how to execute continuous improvement.

Conclusion

This blogpost is a small blogpost about Lean. Lean is in the same category as scrum or agility and I'm convinced they can work together in synergy.

Greetz,

Hennie


donderdag 4 december 2014

Process mining

Introduction

Currently following the course processmining on Coursera and this course is combination of data mining and processmodels. Like the same as with Business intelligence (sort of), processmining analyzes data about processes in an organisation. I'm quite enthusiastic about this approach because it analyzes processes on a scientific manner with data mining. Datamining analyzes data but not with the (direct) aim of looking at processes in an organisation. Processmining does. There is also a relation between BPM (Business Process modelling). In the course sometimes BPM models are used aside petrinets.

Although I've just started with the course, I want to share some interesting things, I've come along during the course. In this blog post I'll describe this.

Defining process mining

The definition of Processmining according to Wikipedia :

"Process mining is a process management technique that allows for the analysis of business processes based on event logs.".

But in my opinion event logs is a bit of a narrow keyword. A more broader definition could be applicable. Think about facts in a star schema or satellite information in a Datavault model that are very often used in business intelligence and data warehousing. These are transactions that happens in the operations of an organisation These are also events. Events that happened. Think about an order entry system with statuses. Sometimes, customers told me how the order entry process worked and when I studied the different statuses an order should have, I sometimes found out that different sequences of the order process were possible. With process mining you can identify undiscovered routes of your business process in automated way. This is truly an addition in the  field of Business intelligence, Lean Six Sigma,  datamining and BPM.

Just a simple example, suppose from the customer you hear that the model is this (orders with order statusses):



But when we study the transactions of the order entry system the following is noticed (records are identified by a case ID (the grouping of the records) and the activity at a certain moment):

Here we see that order 4568 is reopened and this should not have supposed to happen according to the designed model. After analyzing the events in a log or perhaps a transactional modelled star schema the model appears like this (corrected):


It could mean that in the operational process order entry personnel has reopened the order for some reason. If you want optimize the process in order to reduce the wastes (Lean Six sigma) than this is very interesting information. Process mining can do this for you.

Conclusion

Although I've just started with studying process mining, this seems a very interesting approach for analyzing processes with datamining. And, this is also applicable on huge log files and analyzing log files is one of the applications of Big data analytics. 

Hope you have read this blogpost with pleasure..

Greetz,

Hennie

zondag 25 mei 2014

Datavault : Kanban in a Datavault project (part III)

Introduction

I've finished my Lean Six Sigma Orange Belt certification a couple of months ago. For this certification I needed a case study that would justify a certification. I decided to use my project as a base for my certification. In my current project we are developing a analytic platform for analysts with Datavault. We already used a kanbanboard but I thought that some improvements was possible.

We encountered some throughput problems of the implmentations and I decided to investigate our development proces and thought about what could aid speeding up the process. The teammembers discussed our method and we tried to adopt the various techniques of Lean Six Sigma.

One of the subject areas of Lean Six Sigma is Kanban and Kanban can be very useful for making your processes visible and identifying possible bottlenecks in the process. Read more about Kanban on Wikipedia and this free book about Kanban and Scrum. These are very learnful.

This is the approach I have taken (with the development team) in order to develop a (new) Kanban board:
  • Identifying the steps we take in the development process?
  • What do we do when we build Datavault implementations (the objects) ?
  • Who are the customers and who are the suppliers in the process?
    • Supplier, Input, Process, output and Customer  (SIPOC).
  • What are the criteria for moving a card from one phase to another?

This blogpost is one in a series of blogposts about datavault:


Task analysis

At first We decided to take a look at our activities in the project. What are the activities in the project? Well, We came up with this list:
  • Analysis (gaining knowledge)
    • Deskresearch
    • Data-analysis
    • interviews
  • Design
    • Datamodeling (Conceptual, logical, SourceVault and  BusinessVault)
    • ETL
  • Development (DDL + ETL Packages)
    • StagingIn
      • Tables
    • SourceVault
      • Hubs
      • Links
      • Sats
      • EndSats (Effectivity)
      • Refs
      • Other DV Tables
  • Build (DDL + ETL packages)
    • BusinessVault
      • Hubs
      • Links
      • Sats
      • EndSats
      • Refs
      • Other DV Tables
  • BusinessAccessLayer
    • Development (ETL packages)
    • Entities
  • ProcessFlows
    • MasterProcess flows (PCF and MPCF)
    • Input file processing (IFP)
    • StagingIn
    • SourceVault
    • BusinessVault
  • Initial loads (This is for going back in time and resample (historize) the data).
  • ProcessManagement
    • Configuration
  • Test
    • Systemtest
    • Acceptancetest
  • Documentation
    • (Conceptual Datamodel)
    • SourceVault Datamodel
    • BusinessVault Datamodel
    • Functional and Technical descriptions
    • SSIS packages
  • Additional
    • Supply contracts with the datasuppliers

SIPOC

The next step was investigating our working process. What are our phases we actually executing during development of a deliverable? And what were the criteria for moving from one phase to another?


The next step was studying the SIPOC (supplier, Input, Process, Output and Customer). With SIPOC you have a tool that help you to improve a process. This is mostly used during the Define phase int he DMAIC process.


I noticed that there are two kinds of output in a process: Work and Criteria. The criteria says something about go/no go decisions and work is about delivering value to the valuestream, for instance a Datavault model.

The Kanban board

The next step we took was designing a new Kanban board, based on the taskanalysis and the SIPOC schema. I made some designs of the board and We had quite some discussions about the board. The discussion was about finding a balance between not too simple but also not too complicated. If it was too simple it will not help us understanding the process and if it was too difficult people wouldn't accept the board. We finally made this board:


Phases
We have defined the columns as identified (more or less) in the SIPOC schema during the Define process : Analysis/design, Develop, build, test, QA, Ready for production and Production.

Lanes
We introduced two kinds of lanes: Projectlanes and fastlanes. Fast lanes were intended for high priority issues that had a higher priority than the projects that we were running.

Definition of Done (DoD)
And the last part that we added to the board was a Definition of Done row. This DoD were the criteria in the SIPOC schema. These criteria helped us describing the DoD. This helped us agreeing about when a card should be moved from one column to the other, as a group.

The result

Finally, we created a new kanban board. This is shown below.


Conclusion

Kanban can be very useful in a project with a number of teammembers. Developers have to tell something about what they are doing, the impediments they have and what they are planning to do. A Kanbanboard can be very effective when all members of team are working with one goal: deliver value within a certain period of time. I think it's less effective when all members are working on their own deliverable and with their own deadline. When teammembers are working on a collaborative goal more co-operation  and more synergy effects will happen

Greetz,
Hennie