Keep Business Processes Humming
Besides providing a way to view performance data, as with the PeopleSoft EPM example, IBF can be used to accelerate business processes. Since last year, a division of General Motors has been using its own IBF-enabled application, called Covigna, for procurement contract management. It accelerates and improves accuracy of contract creation and acceptance so the revenue-generating work of executing the contract terms can begin much sooner.
The application defines a workflow that streamlines collaboration among contract requestors, sourcing managers, line-of-business execs and legal counsel. Using IBF and Web services, the developers tied SAP ERP and financials as well as their own contract workflow system into Microsoft Sharepoint Portal Server, InfoPath and Word, which serve as the front end. As part of the workflow, workers receive notifications through Outlook e-mail (see screen capture 2). Smart Tags provide the context for e-mail recipients, so, for example, a sourcing manager can decide immediately whether to accept or reject a request without leaving Outlook.
When it's time to draft a contract, the Covigna application automatically launches an appropriate contract template. Using Microsoft's "Schema Attached Document" XML-based technology together with IBF, the contract management application's Authoring Assistant helps users quickly fill in detail. A schema provides an output format for an XML data source. Because XML is hierarchical, a specific piece of data such as a vendor name that's already completed on the document will narrow the choices contextually for all of the levels dependent on it, such as mailing addresses.
Caveat Early Adopter
IBF will make it easier for you to create custom applications like this for your enterprise, but beware of some obstacles.
IBF can make Microsoft development easier, but long-term maintenance might be problematic. To create an information bridge connection, you must first create an IBF metadata repository. Unfortunately, the IBF metadata repository doesn't currently support inheritance, so mapping to a legacy repository that does support inheritance causes data duplication in your model. Therefore, if you have to change something in the metadata that affects many entities, you'll spend a lot of time individually changing every entity rather than simply changing a single object. Having a metadata repository already in place for your back-end application won't spare you the need to create and maintain IBF metadata separately.
Even though you can make multiple metadata repositories available to IBF, an attached schema document can reference only one. If your attached schema document needs to reference more than one back-end application, you must create a single metadata repository that covers all of them. Doing so might complicate your metadata repository maintenance even more.
There's another possible hitch. Unless developers take onerous extra steps, Smart Tags will be triggered by only perfect matches of literal strings. For example, in the PeopleSoft EPM 8.9 example, "Customer Satisfaction" would be tagged, but "Cutsomer Satisfaction" wouldn't. That's not a problem in Covigna, says Covigna developer Sam Yen, because it doesn't rely on users entering the correct text unaided. However, most scenarios for PeopleSoft EPM 8.9's use of Smart Tags do begin with free-form text entry, and it's likely other vendors' applications or your own custom projects will need to recognize misspellings, too.
The Office pane where users interacts with IBF-enabled systems includes a search box that does, by default, recommend words in its dictionary similar in spelling to nonvalid text strings entered there. But the point of Smart Tags is that they prompt users to the existence of relevant information rather than assume users will know to search a particular term.
To enable Smart Tags to recognize slightly misspelled key words, developers can use regular expressions in their application's Smart Tag profiles. If you've got prepackaged software that the vendor exposed to IBF, that vendor could possibly prepackage some of this work for its customers at the dimension level. But dimension members specific to your business, such as employee names, are going to be your developers' problem.
Synonym recognition could also be important in IBF implementations. Your developers can explicitly identify synonyms as entity attributes in the metadata, no matter who originally developed the metadata repository--your company or the vendor. Oracle calls this work a minor tweak that EPM customers can perform.
Look for additions and modifications on the Oracle Developer Network. Oracle is publishing the materials necessary for developers to create their own transformations of source XML from the PeopleSoft Enterprise Warehouse to new displays within the Office Research Task Pane. All it takes is new or modified XML Stylesheet Language Transformation (XSLT) files. The XSLT modifications can be performed by "any first-year IT person just out of school," says Vigeant.
Demand Exceeds Supply, Benefits Exceed Costs
Enterprises are eager to give workers fast access to relevant information. Thirty-nine percent of Intelligent Enterprise readers polled agreed that their companies would deliver information "in context" (from within a productivity app, relevant to the user's identity and current task) at some point in the future (see Listening Post). And vendors know customers want Office integration. Although only a handful of vendors appear on Microsoft's IBF partner page, it's hard to know how many are working in stealth mode on providing prepackaged IBF connections to Office.
It's almost certain that many users in your enterprise could increase their productivity if they could access BI and transactional data directly from within Office applications. However, the longer you wait to do custom development with IBF, the more likely it is that your prepackaged application vendors will do the work for you. If the current metadata management and word recognition limitations would be problematic in your environment, wait for more mature versions of IBF or for corrective aftermarket tools to appear. But if you're eager to get started, you should quantify how much time employees lose every day hunting for information. Harder to quantify, but just as real, are the opportunities those employees sacrifice or the bad decisions they make because they can't get answers quickly enough. Even a conservative pecuniary estimate of those losses is likely to provide a huge potential return benefit to compare against projected development costs.