Business architecture is about the architecture of the various businesses within one company. Banks for example have designed so-called Chinese walls. These are not walls as you would see in real architecture, but they are virtual walls that separate one business (unit) from the other, in cases where both may not influence each other.
This is the case where the bank is doing business with corporate clients (in serving a possible IPO or stock emission) and the brokerage business where brokers may act on information that is sensitive. If the broker in the bank learns about a possible action with a corporate client it can gain money (in an illegal way).
Business architecture is not visible, but should be made visible.
The best example of fraud-prone-architecture comes from the Madoff case.
Business architecture-wise there are three lessons to draw from that case:
1. The profile of the leader who someone is doing business with. Madoff gained "Respect" as having been the president of the Nasdaq stock-exchange. But think about this. Would you trust your money to an (hedge fund) investor who has been president of Nasdaq? Is that a credible biographic path for an investor? A broker (nasdaq) is something completely different than an investor. Would you imagine Warren Buffet become president of Nasdaq or the NYSE? Having worked for Nasdaq one would know all the mazes in the legal net to start a fraud. (but I agree somehow that this is easy knowing once the damage has been done. Hindsight knowledge...which makes it a weak argument).
2. Optimal was one of the funds of Santander who invested in Madoffs hedge funds. Optimal administrators warned for the design "error" in the hedge fund. On a page 35 (source: El Pais) of the prospectus of the hedge fund, was published the article "possibility of Fraud": it stated that "the nor the funds itself, nor the custodian would operate as a custodian." Who then, one might ask.
Business architecture is something that analyst and (risk) managers should make visible by drawing the business and the organization around it.
3. Finally, the profile of a risk manager. That is one similar to that of a (private) detective. The risk manager should never rest, never stop asking questions and never stop to investigate... and a risk manager is not a loner out there at the attic of your organization. Sometimes we all have to play the role of the detective... Investigate when something smells fishy ("a guaranteed return of 10 percent"...hmmm smells ....)
Wednesday, January 25, 2012
Tuesday, November 29, 2011
Business Architecture of Hospitals - Part 12
Organizational policies in the healthcare sector are a difficult area to manage. The reason is that these policies have a generic character but should serve a specific application.
Policies are the translation of the hospital strategy but are detailed for a certain domain. So there are pure medical policies, ICT, human resources, infrastructural policies.
Policies are derived from corporate values. One of such a value could be that the hospital operates on an evidence based way. This is often for the smaller hospitals that have limited space for research and development and follow the trends in the market. Academic or university hospitals can combine such a principle with a more innovative directive to pioneer in certain areas for which the hospital has specialized.
As there are more corporate values, there are also more policies that have to be managed in combination. Innovation and research may be a driver for an academic hospital; "patient safety" is a policy that overrules all other policies in the situation of a conflict.
Policies can be developed "on-the-job." Basically a policy is formed after events and conflicts have already occurred. At the operation start of a new organization there are no policies yet and as things happen, a pattern raises of recurring issues. Policies are like the jurisprudence of law; many things that have happened resemble previous situations. Policies make sure that the decision taking process will be speed up. It is no use to dedicate time to issues that you have dealt with before. Just do what you have done before where the measure seemed to have worked out.
This works until there is a real change, a new conflict or a change in the environment where a new measure is required. And a new policy will be "established" as more of these new cases pass the management agenda.
Policies are the translation of the hospital strategy but are detailed for a certain domain. So there are pure medical policies, ICT, human resources, infrastructural policies.
Policies are derived from corporate values. One of such a value could be that the hospital operates on an evidence based way. This is often for the smaller hospitals that have limited space for research and development and follow the trends in the market. Academic or university hospitals can combine such a principle with a more innovative directive to pioneer in certain areas for which the hospital has specialized.
As there are more corporate values, there are also more policies that have to be managed in combination. Innovation and research may be a driver for an academic hospital; "patient safety" is a policy that overrules all other policies in the situation of a conflict.
Policies can be developed "on-the-job." Basically a policy is formed after events and conflicts have already occurred. At the operation start of a new organization there are no policies yet and as things happen, a pattern raises of recurring issues. Policies are like the jurisprudence of law; many things that have happened resemble previous situations. Policies make sure that the decision taking process will be speed up. It is no use to dedicate time to issues that you have dealt with before. Just do what you have done before where the measure seemed to have worked out.
This works until there is a real change, a new conflict or a change in the environment where a new measure is required. And a new policy will be "established" as more of these new cases pass the management agenda.
Sunday, November 27, 2011
Business Architecture of Hospitals - Part 10
Infrastructure is an organizational component that is often taken into account at the tail of projects. Infrastructural solutions require planning and offer the basic support for the rest of the organization.
In hospitals the main infrastructure is physical oriented. The route patients and visitors have to take (part of the logistical process) are long and depend on their treatment. Now, as the organization changes, the physical locations of surgery units, laboratories, care-units and consulting areas change frequently, the paths visitors have to select will also change. This is much like a supermarket where sometimes the fresh fruit products are at the end of the market, and sometimes the organization changes these to the entrance of the market.
In a hospital a change of locations of where the various specialists "operate" has to be signaled to clients. This is to avoid visitors asking: "where do I find the department of ..."
One way of doing this is my setting up navigation which displays where the specialists rooms are to be found. If these change however, all the signs need to be changed too and this requires a lot of work. It is also possible to change the medical name plates to numbers. Now when there are changes in locations only the main navigation "menus" must be updated which is a minor job.
This is all part of infrastructure, and it is only one element; the physical space and the communication. Other elements of infrastructure are: the communication network, the phone infrastructure, the Interactive voice response that is used at the reception and many more...
When organizing infrastructure an organization must think about requirements. These are not functional like those for the radiologist, gynecologist or surgeon, but these requirements are more general and they support the whole hospital organization.
Thinking about these general requirements is thinking about adjectives like: flexibility, security and availability. The above mentioned example of path indicators is a result of a requirement for flexibility. Then what is only missing is to define these requirements and match them to the infrastructural components. Taking in mind that some set of requirements may cause conflicts; more flexibility (mobile internet, mobile communication) may have a negative impact on the overall security.
In hospitals the main infrastructure is physical oriented. The route patients and visitors have to take (part of the logistical process) are long and depend on their treatment. Now, as the organization changes, the physical locations of surgery units, laboratories, care-units and consulting areas change frequently, the paths visitors have to select will also change. This is much like a supermarket where sometimes the fresh fruit products are at the end of the market, and sometimes the organization changes these to the entrance of the market.
In a hospital a change of locations of where the various specialists "operate" has to be signaled to clients. This is to avoid visitors asking: "where do I find the department of ..."
One way of doing this is my setting up navigation which displays where the specialists rooms are to be found. If these change however, all the signs need to be changed too and this requires a lot of work. It is also possible to change the medical name plates to numbers. Now when there are changes in locations only the main navigation "menus" must be updated which is a minor job.
This is all part of infrastructure, and it is only one element; the physical space and the communication. Other elements of infrastructure are: the communication network, the phone infrastructure, the Interactive voice response that is used at the reception and many more...
When organizing infrastructure an organization must think about requirements. These are not functional like those for the radiologist, gynecologist or surgeon, but these requirements are more general and they support the whole hospital organization.
Thinking about these general requirements is thinking about adjectives like: flexibility, security and availability. The above mentioned example of path indicators is a result of a requirement for flexibility. Then what is only missing is to define these requirements and match them to the infrastructural components. Taking in mind that some set of requirements may cause conflicts; more flexibility (mobile internet, mobile communication) may have a negative impact on the overall security.
Subscribe to:
Posts (Atom)
