While the primary focus of applying EDM to customer service should not be cost containment or reduction, there is still a role for EDM in managing costs. For instance:
One of my favorite BI bloggers, Cyril Brookes, had an interesting post today - What Does Web 2.0 Really Mean for BI’s Future?.
Neil sent me an interesting link yesterday - Less (Information) Is More in which the work of Gerd Gigerenzer, of the Max Planck Institute in Germany is discussed.
Gerd has a new book “Gut Feelings” that sounds like it has a lot in common with Blink by Malcolm Gladwell (reviewed here).
I was talking with Neil Raden and Tom Davenport today on the subject of decisions - what are the various kinds of decisions and how do companies make them and think about making them.
Afterwards I was reminded on something Rob Meredith posted - IT Archaeology: Whatever Happened to SDS? - a couple of weeks ago. It made me think about how we classify problems suitable for Enterprise Decision Management or EDM.
Amit Chembukar and Prasanna Keny of Tata Consulting wrote Trends in Operational BI in BI Review. It's a nice article and they make some good points about the characteristics of the kinds of systems they discuss:
I saw this article by Peter Graham "Building the Analytic Organization". Peter lays out some steps to create an analytic organization but I think he has failed to list the first one! Action "0" must be to establish why you want to use analytics - what is the business purpose?
Bhaskar Sharma of HCL wrote me a little while ago and asked about business rules and the software development life cycle (SDLC).
Periodically I get asked about bringing business rules into the Rational Unified Process or RUP. RUP and the Enterprise Unified Process are designed to apply UML and best practices in a formal way.
Nik Malik posted here on why he thinks a pattern known as "dependency injection" beats out rules engines.
I saw this article on CIO magazine - Five Things CIOs Should Know About Software Requirements. It seems to me that there is one more thing (at least) that they need to know about requirements:
Business rules are NOT requirements