2009-07-14
Hard to Use Health Information Systems
At three recent medical visits, the nurse or physician made comments to me on their health information system (the same one). I doubt they knew that I worked in the domain. The thrust of all three of their comments was that their need to interact with the system impeded the flow of their work and the personal attention they wanted to give to their patients. For example, before administering a medication, one has to
- Scan the patient’s bracelet.
- Confirm the patient’s identity.
- Scan the medication bar code.
- Confirm the choice of medication.
- Confirm that, yes, one actually has just administered the medication to the patient.
The caregivers agreed that it was important to keep good records; one of them said that, in her thirty years’ experience, she had always kept paper records. Had she forgotten how hard it was to keep paper records, more often after the fact than at the point of care? Could it be the very length of their experience that made it hard for them to adapt to the use of electronic medical records? Might it be that the technology is still too immature to support ease of use? Would there be a way to make their existing system easier to use, through training, reconfiguration, or redesigned work flow?
2009-05-28
First Take on the Guide to the Business Analysis Body of Knowledge (BABOK)
This is my first foray into the body of knowledge (*BOK) genre. If there’s one thing this guide is not, it’s an invitation to become a business analyst. The text is anything but inspiring. Maybe its purpose is to serve as a source document for the CBAP exam also produced by the International Institute of Business Analysis (IIBA). One needs to become a member of this institute in order to read the guide, if not sit for the exam.
I don’t pretend that the following comments are systematic. They might even show my ignorance of some of the commonly understood backdrop to the profession. You can take them as simple notes on my first reading of the document.
The Good
I like the idea of summarizing the body of knowledge of a profession. It would be interesting to look at the history of the genre and to critique the Guide to the BABOK as an instance of the genre.
The Bothersome
An unresolved tension between the stated purposes of the guide and of the BABOK reveals itself throughout the document. The stated purposes are:
- To define the profession of business analysis
- To serve as a baseline that allows
- Business analysts to discuss what they do in common terms
- Training and certifying bodies to ensure that business analysts attain the skills they need to be effective
- People who work with and employ business analysts to know what to expect from the latter
- To provide a framework for
- A normative description of business analysis tasks
- An understanding of how these tasks deliver value to an organization
The tension between these purposes arises on one hand from the implicit need of this document both to describe and to prescribe the concepts and tasks that a business analyst performs and, on the other hand, from the abstraction of these concepts and tasks from any given theory of organizational behavior or practical methodology.
The text is, on the whole, descriptive of the tasks that a business analyst does. The tone is heavy and overly formal. Excessive use of the passive voice makes for dense and sometimes confusing reading. For example, “It is expected that at some point while performing elicitation that sufficient material will have been elicited from the business experts to allow analysis activities to begin.”
Oddly, in the midst of many of the descriptions, the authors switch to unmarked verb forms, either for fragmentary infinitive phrases or for the imperative mood. This mood switching maintains the confusion between descriptive and prescriptive purposes, with no transition. If some of the text is prescriptive and some of it, simply descriptive, the authors could have more clearly indicated that such is the case. I would expect to find imperative mood rather in procedural writing, which this document is not.
One final point that struck me as I read is the organizational role of the business analyst. The document clearly states that a “business analyst is any person who performs business analysis activities, no matter what their job title or organizational role may be.” And, of course, the presumed actor of all of the tasks described is definitely the business analyst, whose profession the authors intend to stake out in this guide. Nevertheless, the authors do not engage in any discussion of the various manifestations of the role of business analyst in different organizational settings or methodologies. What are the advantages of having specialized business analysts as opposed to having the role filled by other professionals? What is the nature of the adaptations that teams need to make to the BABOK to successfully perform business analysis in the full range of possible adaptations? How does one do business analysis in an agile environment?
International Institute of Business Analysis | The Guide to the Business Analysis Body of Knowledge
Posted from Diigo. The rest of my favorite links are here.
Rich Analysis 