Steuer V0.2 – making progress with my iPhone app
Over my last few train rides I’ve managed to make some progress in making my app a bit nicer.
This is what the old version looked like:
Apart from a few “under the hood” things (like moving to a new version of XCode and the SDK, so the simulator looks like an iPhone 4 now), I’ve improved on the following items:
- switched to a table-based view
This makes the inputs (Eingaben) and results (Ergebnisse) pretty self evident. I’m still going to tinker a bit with the view as there is one row that wouldn’t quite fit on one screen and I don’t want the app to start scrolling. - added a “title bar” (called navigationItem in iPhone-speak)
I couldn’t quite figure it out how to do that for the simple version where I didn’t have to write a controller for the main app screen. - ditched the “Berechnen” button
After changing the inputs, the results are automatically calculated.
Here’s where I am now:
I think that is looking a lot better than V0.1, but there is still a lot to do – both from a design (colors anyone?) and a functionality standpoint, but at least I’m making some progress. I’m hoping to get a bit more done in the “free” days after Christmas, but it already looks like a lot of days are filled with visits to family and friends, and that is certainly important, too. I’ll keep you posted!
Unit Testing an iPhone App – Not important to Apple?
After the base functionality of my iPhone app was in place, I wanted to have a closer look into unit testing. I try to use unit testing where it makes sense when developing for my customers, so I wanted to do that for my own app as well. I was encouraged that there was some documentation in the Apple developer’s guide, and I was really looking forward to putting the framework to use.
Restructuring my App for testability
Before being able to properly test the tax calculation functionality, I had to a bit of restructuring to do in order to properly isolate the functionality I wanted to test and to separate it from the GUI. I pulled the tax calculation into its own class and made the GUI use this TaxCalculator. This separation of concerns is one of the benefits of using a Test Driven Approach – it forces you to think about testability and separation of concerns if you want to have an easily testable class. The changed were totally unnoticeable to the user, but added some value because the code is now much easier to understand and to maintain. It took me less than an hour of development time, and that was time well spent.
Initial Problems with SDK 4.1
The next step was reading up on Unit Testing with the iPhone SDK. There is a chapter in the iOS Development Guide that describes how to add tests to your project. From the start, I was getting strange errors even though the tests seemed to pass. As I was developing these tests while riding the train, I played a bit around in order to avoid the problems, but didn’t have any success. I added a few tests for the TaxCalculator, but ran into some more strange behaviour.
Some Progress with SDK 4.2
When I was back home, I googled for my problems and quickly found that it was a problem with SDK 4.1 (thanks to this Stackoverflow question). There seemed to be a workaround in 4.1, but as the problem was fixed in SDK 4.2, I just decided to upgrade my SDK which I wanted to do anyways.
After that, I had the next problem – XCode was telling me that my “base SDK was missing”. Googling for that problem I quickly found an easy fix for this issue as well (the one I used was on John Alexander Rowley’s blog, but there is a number of helpful hints across then net. After that, my tests were finally running without any errors and I was finally able to focus on writing test cases.
However, I soon ran into a lot of problems in properly checking what the tests were doing and if my app was working fine. I’m usually trying to reserve judgment, but in this case I can’t put it any other way:
What was Apple thinking?
Using the Apple supplied Unit Test library, the tests are only run during the build phase. Running tests during the build phase is not a bad idea, it can prevent building an app if some tests are failing. But running it only during the build phase has some serious drawbacks: Messages sent to the log do not show up in the debugger console (at least they show up in the system console), but more important: You can’t debug the tests!! (I should note that there are some descriptions on how to set up a separate target that would allow you to debug the tests, but the procedure is very complicated – like setting the environment variable CFFIXED_USER_HOME to "${HOME}/Library/Application Support/iPhone Simulator/User". I gave up on it after unsuccessfully trying for an hour or so.)
I have no idea how anyone can think that what is currently delivered is good enough to use. No one who has never used Unit Tests and pretty much wants (or has) to use it will endure the procedure to make it work. It just seems to be some item on a list that Apple wanted to tick (“Unit Testing? We have that.”) but wasn’t really interested in. Very “un-Apple” …
Switching to GHUnit
Luckily, there seems to be a good open source alternative to the Apple Unit Testing framework, name GHUnit (named after it’s developer, Gabriel Handford) which can be found at http://gabriel.github.com/gh-unit/index.html. It was very simple to download and add to my project. Within 15 minutes I had my project use GHUnit and I was able to run the previously developed tests within the simulator:
It also enabled me to log to the console and debug my test cases in the XCode debugger just like any normal app – without having to jump through any hoops. You may argue for a nicer interface (color anyone?), but that is certainly a minor issue. After the disappointing Apple framework, GHUnit delivered on what I was looking for. I’m hoping that the framework will hold up under all the testing I want to throw at it in the next weeks!
Calculating tax owed – My First iPhone App
As indicated in my latest blog posts, I’ve started to dabble in iPhone development. As a starting point, I have programmed a little app that calculates income tax owed based on money earned.
Use Case
The use case for this app is based on my personal situation as a freelancer in Germany. The situation is probably similar to other countries, and I might build similar versions for non-German markets.
As a freelancer in Germany, when you get paid, there is no tax withheld as it would be when you are an employee. At the end of the year, you have to declare your earnings, tax is assessed and then you have to pay. As this is a substantial part of your earnings (30-40% is a typical number here in Germany), you better make sure that you know how much of your earnings is actually money you can spend. It is also a good idea to put away the money you expect to pay for taxes. (I like to save the amount in a money market account, so I even have a chance to earn some income on it, even if there’s not much to make with the way interest rates are these days.)
So the App basically asks you how much money you have earned in a month and shows you how much taxes you would owe on this amount. Sounds really simple, but nothing with taxes is ever that simple:
- There is some additional sums that has to be included in the taxable amount. In Germany, the main one is called “Geldwerter Vorteil” or GWV for short – a monetary equivalent for non-monetary benefits that you get. The “classic” example is a company car that you can use privately or for riding to your place of work.
- There are different components to income tax, such as the base rate, “Solidaitätszuschlag” (an add-on income tax that was originally introduced to aid East Germany after unification) or “Kirchensteuer” (“church tax” which is collected by the state and then re-distributed to the churches).
- The tax rate itself is not one simple formula but has different formulas for different ranges.
So even if the use case is not all that complicated, it is also not trivial to build a decent app for that.
The App V0.1
Here is a screenshot of the first, simple version of the app:
On the top, you can enter the money earned (“Einnahmen”) and the GWV. Below the ‘Berechnen’ (calculate) button the different components of the tax and the full amount of tax owed is shown (“Gesamt-Steuer”). In addition, the tax rate and the earnings after tax are displayed.
From a functional viewpoint, there is very little that is missing for the use case I outlined above:
- Kirchensteuer is dependant on whether you are a member of a church and your location. There has to be some configuration, probably in a new view.
There are a few things that would be nice to have:
- The last values should be saved and reloaded after the app start.
- In order to calculate GWV for car use there are some standard rules. Instead of entering the final value, the way this is calculated should be made available .. another configuration view.
After that, the improvements are not so obvious:
- make the interface prettier (icon, title bar, colors)
- use better formatting of the values (separators, currency symbol)
- instead of individual labels and fields try out a table-based view (should look “nicer” and also offer an easier way to integrate the configuration views)
- explore a subview with ads in order to monetize the app (instead of selling it)
- explore alternatives for smarter entry of values (instead of keyboard, use dials and/or gestures)
The last item is especially important for me, as I want to develop apps that make good use of the iPhone’s capabilities. In my view, today there is not much use for simple data entry iPhone apps that could just be a web form. In order to delight the user, you have to be able to make things better, easier and unique to stand out from the crowd of apps in the app store. This may be tricky for a “boring” tax app, and you also have to find a balance between “clever” and “easy to use”, but I’m willing to explore these areas and see what I can come up with.
I’ll post some news once I’ve improved the “raw” app I have now.
Discussing an iPhone App: Settlers of Catan
Over the last weeks, I’ve been thinking about starting some development for the iPhone. There are some ideas in my head of what I could do, but nothing specific yet. Only thing that I’m sure is that I don’t want to do another “me too” program, but something that really uses the iPhone’s strengths.
For example, a lot of mobile apps I see just let you enter data on the iPhone using the traditional “keyboard” and “picker” methods. I’m pretty sure that some gestures may be helpful and allow for quicker entry. Also, oftentimes “guessing” from a GPS-location or time-of-day may offer some good default values. I hope that this will be a road that I’ll be able to explore a bit more.
Because of all of this, I’ve been paying closer to attention to things I like and dislike about some of the apps and games I’m using.
I like playing the occasional game on the iPhone, and in the last few weeks I was playing a lot of Siedler of Catan (Settlers of Catan in English). Just to be sure: The adaption of the board game is done quite well, the computer players have different strengths, so the game provides fun and entertainment for a long time. Well spent 4€ (or 5$)!
However, there are a few issues that I have. The start of the game features an elaborate animation .. but there is no way I have found to get straight into the game. So every time you start the app, after waiting a few seconds for the animation to load, you get the start of the animation
After tapping on the screen, you get another splash screen:
where the game even tells you to tap the screen (“Bitte Bild berühren”). Then you get the main game menu
where you can hit “Spiel fortsetzen” to continue the ongoing game.
That’s three useless taps (and probably 10 seconds of time) that I would consider bad style for an iPhone app. (It’s okay for a PC game, but not for an iPhone app that gets frequently stopped and restarted.)
There are a few other examples where a bit more thinking would have helped create a better experience. For example in this screen you have only three options, but the graphics don’t fit the screen so there may be some scrolling involved:
With just some more work, the graphics would fit the screen. Also, swiping doesn’t really work here, instead you have to use the provided arrows.
I’m sure that these issues arise from trying to be consistent with other versions of the same game, but I would think that some more care should have been taken while adapting the game to the iPhone.
So five stars for the basic game, but only one star for the iPhone adaption.
Have you built your DQ trust today?
For German readers: Es gibt eine deutsche Version dieses Blogeintrags.
In the last time, there have been quite a few posts on using “shame” as a tool for improving data quality. Here are just three from the top of my head:
-
The Scarlet DQ, both by Jim Harris at OCDQBlog
Picture by Okinawa Soba, taken from flickr with a cc license
I’ve added some comments to these posts that I think that they are missing something. I wasn’t quite able to put my finger to it, not sure how to grab the “missing thing”, not really able to give it a name. In order to move the discussion forward, I’ve decided to go with “DQ trust” and try to explain my thinking a bit more. Let me know in the comments what you think!
The problem I see with the “public humiliation” aspect of what Rob and Jim are describing: It will only work in a certain environment – when the “riot act” gets what I would call a “wink wink, nudge nudge” aspect. The “culprit” understands why the reaction is coming, but the whole thing is so much over the top that it can’t really be taken seriously. This results in taking the sting out of the “public humiliation” aspect and the riot act achieves its purpose.
In order for this to work, there has to be one of two things: Either you have to be a really good comedian (and I’m certainly not) so that you can spring this on a person you’ve hardly ever dealt with before. If your act backfires, you’ll also have to deal with that person’s boss, and I have found humor to decline when moving up the corporate ladder. Pretty risky to rely on that.
That leaves the second option: Your riot act has to have a background to it, and you must have built a reputation as a fervent defender of data quality in your organization – you must have built a trust in your data quality judgment. This way, a person or his boss can understand that your reaction is aimed at improving data quality, and not at public humiliating data quality villains.
Too often I find that people do not take enough time to build this data quality trust. As they say it takes a long time to build trust, but only a moment to destroy it forever. Here are some ideas of what to do to build the trust:
- reserve judgment on someone’s actions for as long as possible – try to find out why people do things a certain way before telling them they are idiots
- admit that you don’t know everything and try to learn constantly by interacting with different people from different departments to get a 360° view on the issues
- help people to solve their problems – then they will be much more willing to help you when you need their support
- make sure to explain data quality in terms the person understands – a business user doesn’t care too much about referential integrity unless you can explain how it affects his daily work
- don’t be too academic in your data quality requirements – it doesn’t make sense to require perfect data quality for data that is never used
Even with this, whenever a new data quality issue comes and I’m shaking my head why anyone would come up with this harebrained scheme, I ask myself whether I’ve built enough trust to shame the person about it or not. Almost always, I come out on the side of caution and try to be firm on the issue, but avoid assigning personal blame. In the short term, this may not be quite as satisfying as “venting”, but has a much better chance of long-term success.
Heute schon das Vertrauen in DQM erhöht?
Für englisch-sprachige Leser: There is an English version of this post.
In der letzten Zeit wurde einige Blogposts veröffentlicht, in denen ein Pranger als Mittel zur Verbesserung der Datenqualität diskutiert wurden. Hier sind einige englisch-sprachige Beispiele:
Picture by Okinawa Soba, taken from flickr with a cc license
Bei diesen Beiträge hatte ich das Gefühl, dass die Reaktion zwar menschlich verständlich ist, aber der Sache eher schadet. Um die Diskussion dazu weiter zu führen, möchte ich meine Gedanken zum “Vertrauen in DQM” etwas weiter ausführen und freue mich über Kommentare und andere Sichtweisen.
Das Problem, das ich mit dem “öffentlichen Anprangern” aus den Posts von Rob und Jim sehe: Ein solches Vorgehen wird nur unter engen Bedingungen funktionieren – wenn das Anprangern mit einem Augenzwinkern erfolgt. Am einfachsten ist es, wenn der “Beschuldigte” von sich aus versteht, was falsch gelaufen ist – dann kann der “Anschiss” so übertrieben sein, dass er nicht ernst genommen werden kann und es so zu keinem persönlichen Angriff kommt, aber der Hinweis trotzdem aufgegriffen wird.
Damit das funktioniert, sehe ich zwei Möglichkeiten: Man ist so witzig, dass ein “Anschiss” an einen neuen Kollegen zu einem Schmunzeln führt – ich selbst bekomme das mit Sicherheit nicht hin. Zudem birgt es das Risiko, dass das Ganze nach hinten losgeht und man dann sein Verhalten mit dem Vorgesetzten des Kollegen besprechen muss. Nach meinen Erfahrungen werden solche Gespräche immer humorloser, je weiter es in der Firmenhierarchie nach oben geht. Insgesamt sehr riskant, sich auf sein komödiantisches Talent zu verlassen.
Damit bleibt die zweite Möglichkeit – das Anprangern erfolgt nur in Ausnahmefällen und erst, nachdem man Vertrauen in DQM aufgebaut und den Beteiligten klar ist, das es um die Verbesserung der Datenqualität geht und nicht darum, jemandem die Schuld für Probleme in die Schuhe zu schieben.
Leider nimmt man sich selten genug Zeit zum Aufbau des dafür erforderlichen Vertrauens, vielmehr kann mühselig aufgebautes Vertrauen mit einer unbedachten Äußerung wieder verspielt werden. Hier sind ein paar Ideen, Vertrauen in DQM zu schaffen:
- eine Beurteilung sollte so spät wie möglich erfolgen – man sollte erst versuchen herauszufinden, warum Leute bestimmte Vorgehen gewählt haben, bevor man sie als Idioten bezeichnet
- Man kann gerne zugeben, auch nicht alles zu wissen und laufend dazuzulernen, in dem man mit so vielen Leuten wie möglich spricht, die verschiedene Blickwinkel auf ein Thema haben
- Unterstützen Sie die Leute bei der Lösung derer Probleme – dann ist die Bereitschaft größer, auch bei DQ Problemen zu helfen
- Datenqualität muss abhängig vom Zuhörer erklärt werden – ein Fachbereich interessiert sich nicht für referentielle Integrität, wenn man ihm nicht erklärt, was das in seiner täglichen Arbeit bedeutet
- Seien Sie nicht zu akademisch in Ihren DQ Anforderungen – es macht keinen Sinn, bei kaum verwendeten Daten eine perfekte Datenqualität zu verlangen
Selbst mit dieser Grundeinstellung muss ich oft erst einmal den Kopf darüber schütteln, auf welche schwachsinnigen Dinge einige Benutzer kommen. Dann frage ich mich aber, welche Reaktion ich ernten würde, den Benutzer damit ein wenig aufzuziehen. In den meisten Fällen gehe ich dann etwas vorsichtiger vor und diskutiere über die Auswirkungen der Fehler anstatt persönliche Schuld zu suchen. Das ist kurzfristig nicht ganz so befriedigend wie “Luft abzulassen”, hat aber langfristig viel bessere Erfolgsaussichten. Wie reagieren Sie in solchen Situationen, welche Erfahrungen haben Sie gesammelt?
Assessing Data Quality – Improve vs. Maintain
For German readers: Es gibt eine deutsche Version dieses Blogeintrags.
Last week, I was discussing measuring Data Quality with a customer. For a while it seemed we couldn’t agree on anything, until we realized that we were talking about different types of DQ projects:
- A project geared at improving data quality in a specific area
- An ongoing effort to make sure data quality stays within accepted levels
Once we talked about these different types, agreement came very easily.
Improving Data Quality
In this type of project, there is an important business reason that requires improving the data quality. Typically, you start with a large number of errors and have to reach a much improved level. In some cases, this level has to Zero, but typically a low number (say, 10) of error cases is acceptable. Examples of this type of DQ project include meeting regulatory requirements or the migration of data to another system.
This is a project in the strict sense: You have to reach your goal by a fixed date. As often these days, the goal has to be clarified after the project has started. For a data quality project this includes identifying important data areas to be improved, defining rules that the data has to conform and a way of identifying non-complying data. When this step is completed, you end up with a number of DQ Measurands (see my previous post on Describing DQ Measurands) and an automated way of measuring the data quality for each specific measurand. Typical projects I’ve worked on had a list of 20 to about 100 measurands that changed a bit over time, but was relatively stable after the initial definition phase.
The main questions that have to be answered in this type of DQ project are:
- Which issues have been raised and which have been resolved? Which do we still have to work on?
- Are we on track to getting to an acceptable level of Data Quality by the end date?
Maintaining Data Quality
In contrast to the “Improvement” type of project, a “Maintain” type does not necessarily have an end date but is an ongoing effort. (It may start towards the end of an improvement project when most issues are resolved and should stay that way until the project ends.)
Most of the definition work has already been done by improvement projects, and the maintain project “inherits” these results. Again, the number of DQ measurands may be quite high – even higher than in an improvement project, as over time the rules of multiple improvement projects move into maintenance. The data quality is usually at an acceptable level, so the type of questions are different:
- Have there been changes that require action?
- How well do the rules cover all the data in the organization?
Assessing DQ Measurements in different types of DQ projects
A DQ measurand can be defined without having to take into account what type of project it is used for. But interpreting the measurements has to take the project context into account and leads to different interpretations in order to answer the question. My customer and I are still working on the specifics, but identifying the different types of projects helped us gain a shared understanding.
Beurteilung der Datenqualität – Verbesserung vs. laufende Überwachung
Für englisch-sprachige Leser: There is an English version of this post.
Letzte Woche sprach ich mit einem Kunden über die Messung von Datenqualität. Für eine Weile schien es, als ob wir uns auf nichts einigen konnten, bis wir erkannten, dass wir über verschiedene Arten von DQ-Projekte sprechen:
- Ein Projekt zur Verbesserung der Datenqualität in einem bestimmten Bereich
- Laufende Überwachung der Datenqualität, um ein akzeptables Niveau sicherzustellen
Sobald wir über diese verschiedenen sprachen, kam Vereinbarung sehr leicht.
Verbesserung der Datenqualität
Bei dieser Art von Projekt, gibt es einen wichtigen Grund zur Verbesserung der Datenqualität. Normalerweise startet man mit einer relativ großen Fehlerzahl und muss sich auf ein akzeptables Niveau verbessern. Oftmals bedeutet dies 0 Fehler, oft ist aber auch eine kleine Fehlerzahl akzeptabel (z.B. 10 Datensätze, die ggf. manuell migriert werden können). Beispiele für diese Art von Projekten ist die Einhaltung regulatorischer Anforderungen oder die Migration auf ein anderes System.
Hierbei handelt es sich um ein Projekt im engeren Sinne: Es gibt einen festen Endtermin. Wie so oft muss das Ziel zunächst genauer definiert werden, nachdem das Projekt gestartet ist. Bei DQ Projekten beinhaltet dies die Identifikation relevanter Datenbereiche, die Erarbeitung Regeln, denen die Daten genügen müssen, und ein Verfahren zur Ermittlung der fehlerhaften Datensätze. Am Ende dieser Phase hat man eine Reihe von DQ Messgrößen (siehe meinen Beitrag zur Definition von DQ Messgrößen) und eine idealerweise automatische Möglichkeit zur Durchführung von Messungen für diese Messgrößen. Ein Erfahrungswert aus meinen Projekten: Nach der anfänglichen Definitionsphase hatte man eine Liste von 20 bis etwa 100 Messgrößen, die für den Rest des Projektes relativ stabil war.
Die wichtigsten Fragen, die in dieser Art von DQ-Projekt beantwortet werden müssen:
- Welche DQ Probleme wurden aufgeworfen, an welchen müssen wir noch arbeiten und welche sind schon gelöst?
- Sind wir im Plan, um das gesetzte Zielniveau vor dem End-Termin zu erreichen?
Laufende Überwachung der Datenqualität
Im Gegensatz zu Verbesserungs-Projekten gibt es bei der laufenden Überwachung kein Enddatum, es handelt sich um eine kontinuierliche Maßnahme. (Teilweise gehen auch Verbesserungs-Projekte zum Ende in eine Überwachungs-Phase – die meisten Probleme sind bereits gelöst, es muss aber immer noch sichergestellt werden, dass ein akzeptables Niveau gehalten wird.)
Oft sind viele Vorarbeiten für die laufende Überwachung bereits durch ein Verbesserungs-Projekt geleistet. Da in die laufende Überwachung DQ Messgrößen aus mehreren Projekten eingehen, hat man hier oft eine noch größere Zahl an Messgrößen.
Da die Datenqualität meist schon auf einem akzeptablen Niveau ist, stehen hier andere Fragestellungen im Vordergrund:
- Gab es Veränderungen, die ein Eingreifen erforderlich machen?
- Wie gut decken die bestehenden Regeln den gesamten Datenhaushalt ab?
Beurteilung von DQ Messungen in verschiedenen DQ-Projektarten
Eine DQ Messgröße kann unabhängig von der Art des Projekts definiert werden, in dem sie verwendet werden soll. Allerdings ist bei der Beurteilung der Projektkontext zu berücksichtigen, so dass bei der Beurteilung unterschiedliche Fragen beantwortet werden müssen. Im laufenden Projekt arbeiten wir noch daran, wie diese Beurteilung sinnvoll erfolgen kann – aber mit den unterschiedlichen Arten von DQ Projekten haben wir eine gemeinsame Basis für die weitere Arbeit geschaffen.
The DQ Cycle – a Procedure for dealing with Data Quality issues
For German readers: Es gibt eine deutsche Version dieses Blogeintrags.
In the past, I have outlined elements to take into account when starting a DQ initiative. This post describes how to deal with Data Quality issues.
Some Background
The Deming Cycle is an established iterative four-step problem-solving process typically used in business process improvement. It is also know as PDCA for its four phases:
- Plan
Establish the objectives and processes necessary to deliver expected results. - Do
Implement the new processes, often on a small scale if possible. - Check
Measure the new processes and compare the results against the expected results. - Act
Analyze the differences to determine their cause. Each will be part of either one or more of the PDCA steps.
(Adapted from the wikipedia article on PDCA.)
Overview
The DQ Cycle is an adaption of this general framework to Data Quality. I’ve used this framework at a number of customers with good success. The general idea is pretty simple and easy to follow, but it is an excellent reminder to make sure you’ve crossed all the T’s and dotted all the I’s.
The DQ cycle has the same phases as the Deming cycle. It describes how to deal with a single DQ problem that has been identified. This means that there may be a number of DQ cycles going on at the same time, each cycle dealing with its problem, and each of these cycles may be at different points in the cycle.
As you may have noted, the description started with the term “DQ problem that has been identified”. In order to accommodate this “problem identification”, there is an additional “Init” phase that kicks off a new DQ cycle:
So we end up with these phases:
- Init: A new DQ problem is identified
- Plan: You analyze the problem and decide on a course of action
- Do: The bad data is corrected
- Check: You verify that the DQ problem is resolved
- Act: You identify and implement measures to prevent the problem from re-occurring
These phases will be described in more detail in the following posts.
Der DQ Kreislauf – ein Vorgehen bei DQ Problemen
Für englisch-sprachige Leser: There is an English version of this post.
In den letzten Beiträgen habe ich einige Aspekte dargestellt, die beim Aufbau einer DQ Initiative relevant sind. Dieser Artikel beschreibt, wie man bei konkreten DQ Problemen vorgehen sollte.
Einordnung
Der Deming-Kreis ist ein bewährter, vier-stufiger Prozess, der üblicher Weise zur Qualitäts-Verbesserung eingesetzt wird. Er ist nach seinen Phasen auch als PDCA bekannt:
- Plan
Erkennen von Verbesserungspotentialen, die Analyse des aktuellen Zustands sowie das Entwickeln eines neuen Konzeptes - Do
Ausprobieren und praktisches Optimieren des Konzeptes mit schnell realisierbaren, einfachen Mitteln - Check
Überprüfung des realisierten Prozessablaufs und seiner Resultate - Act
Untersuchung der Abweichungen und deren Ursachen, die dann wieder in eigenen PDCA-Schritten bearbeitet werden
(Basierend auf dem Wikipedia Artikel zum Demingkreis.)
Überblick
Der DQ Kreislauf ist ein Anwendung dieser allgemeinen Vorgehensweise auf DQ Probleme. Diesen Rahmen habe ich bei mehreren Kunden mit gutem Erfolg eingesetzt. Die Grundsätze sind recht einfach, stellen aber eine gute Checkliste dar, um alle erforderlichen Punkte auch abzuhaken und so eine nachhaltige Lösung der DQ Probleme sicherzustellen.
Der DQ Kreislauf hat die gleichen Phasen wie der Deming Kreis. Er beschreibt, wie man mit einem einzelnen identifizierten DQ Problem umgeht. Dies bedeutet, dass es zeitgleich mehrere DQ Kreisläufe in unterschiedlichen Phasen geben, die jeder ein einzelnes Problem zum Schwerpunkt haben.
Die obige Beschreibung bezieht sich auf “identifizierte DQ Probleme”. Um diese “Problemidentifizierung” einzubeziehen, gibt es eine weitere “Init”-Phase, die einen neuen DQ Kreislauf auslöst:
Somit besteht der DQ Kreislauf aus folgenden Phasen
- Init: Ein neues DQ Problem wird identifiziert.
- Plan: Das Problem wird analysiert und eine Vorgehensweise zur Korrektur festgelegt.
- Do: Die falschen Daten werden korrigiert.
- Check: Es wird geprüft, ob das DQ Problem durch die Maßnahmen auch tatsächlich gelöst ist
- Act: Es werden präventive Maßnahmen erarbeitet und umgesetzt, um ein neues Auftreten des Problems zu verhindern.
Details zu den einzelnen Phasen werden in folgenden Beiträgen diskutiert.
