Saturday, October 31, 2009

Business Process Management Example: Selling cars at a dealer’s auction.

This is an example of business process management and shows a snapshot of a software tool that is used. One of the companies that are a subsidiary for the company that I work for is responsible for auctioning off cars. So for the example of business process management I will discuss the business process in getting that car from the lot to the auction block. This explanation will be very high level as to provide the important details in the process and will not cover the intricate details of every step necessary to sell the car. So the steps I provide may not be the exact steps that the company takes (and the software tool is not used by the particular company), but the purpose is to illustrate how business process management works. I will use the term ‘Company’ to refer to the business responsible for auctioning off the car.

At the beginning of the process the car will be received from an auto salvage shop location. Once the car is delivered to the Company it will be necessary to take pictures and collect information about the car to place into the Company’s records. This information will contain data such as the make, model, year, color, and any other important information about the car history. After the information is recorded the next step is to prepare the car to be sold at the auction. This may require repainting, dent removal, or even significant body work (or course the car should be sellable at a value higher than the work performed). All of this information is recorded and the car is then passed off to the necessary departments to have the work done. After all the work is done and the car is ready to be placed on the auction block another set of pictures is taken and entered into the Company’s records. These pictures will be the one made available to dealerships that may be interested in purchasing the car. The car is then shipped off to the location of the auction and on the day of the auction the car is sold (hopefully!). Once the car is sold there is another set of paperwork done to record buyer and price information as well as any other pertinent information about the trade. This information also needs to be entered into the Company’s records. That is the last piece of information that is collected in the Company’s records about the car.

The software that I used to illustrate the process is called Stellent Imaging and Business Process Management (IBPM) that can be used to facilitate this process. The tool that is used is called Process Builder and you can read more detailed information by clicking here (starting on page 423). The software allows a lot of powerful functionality and for the sake of time and understanding I have only designed a simple diagram that illustrates the business process. I have listed come reference URLs at after the picture for additional information.



(click on image above to enlarge)

References:

Oracle Imaging and Process Management (Stellent IBPM)

Oracle Business Process Management Suite

Oracle/Stellent Documentation

Tuesday, October 27, 2009

Google

Google really does offer a lot of cool stuff in the area of integration. Like this one for people who use Google Voice (screenshots*, not the real thing!):



It's a "Call Widget" that lets people call me without knowing my phone number. Click it and you are asked to enter your name and phone number.



When you click the "Connect" button you get a phone call at the number you entered and then it will ring my phone number. I can also set up the widget so it goes directly to voice mail. There's also some other cool stuff, but I don't want to sound like an ad, so I'll stop now. *grin*

I don't know how the underlying program works, but I'd say that this "widget" would also likely meet the broader definition of a "portlet" as discussed in our presentation last week.

* I am not posting the real widget simply because I don't want every random web surfer in the world to be able to leave me messages or call me for no good reason.

Sunday, October 25, 2009

CIS 8020 Assignment 2 UT Olympic Guide Google Map

With the Olympics coming to Rio De Janerio in 2016 MO Tourist Attractions (imaginary company) wants to be able to provide tourists the ability to obtain quick and accurate information on the excellent places to dine, best to shop and locations of all the events. A graphical interface would provide the tourist a much better opportunity to visually get an idea of these ‘hot spots’ than just reading some text-based article or brochure. With leveraging the simple API as below the users will have the option of selecting if they want to see only places to shop (represented by ‘S’), places to dine (represented by ‘D’) or place of Olympic events (represented by ‘E’).

Google Map API is an great candidate solution to address this issue. It will generate a static map that can be integrated to Mo Tourist Attractions website and allow the users to select the different options (dine, shopping, events) that they want to see. A prototype is below:



When compared to other solutions , this option would be quick to implement and doesn’t require a lot of work on the back end of the website. It can be published and modified as necessary by any one of the agents at the tourist office and does not require advanced knowledge of website design. The time that it takes to load the map is fairly quick and will be very low maintenance.

Additionally MO Tourist Attractions can look at expanding the Google MAP API by integrating the Google Calendar API. This will allow the mapping of times and specific olympic events to locations and also any special occassions that may be happening at the dining restaurants (i.e. Olympic Atheletes dining at certain restuarants).

Friday, October 23, 2009

CIS 8020 Assignment 2 PW Visualization API - Charts

A college admissions/recruitment office typically receives applications for three different terms and from three different types of students at any given point in time. The department management has requested a quick way to visually demonstrate what combinations of types are terms are being received from week to week for use in a newsletter that is posted on the organization's internal website.

The Google Visualization API is an excellent tool for implementing this solution since it can automatically create interactive charts to display the data. In this example I created a simple spreadsheet in Google Docs that contains the data for the week. Two charts have been created in order to show the data both by student type and semester:







This style of implementation was chosen because the code to create the charts only has to be written once. The person who writes the newsletter never needs to touch the code, they simply update the data in the Google Docs spreadsheet and the charts are instantly updated.

A less elegant and more labor intensive solution would be to create the chart in a desktop spreadsheet program (e.g. MS Excel or OpenOffice.org) and then manually generate an image that would then be uploaded to the web server and included on the webpage.

NOTE: There is a compatibility issue with this code! The charts display without error under Firefox and Google Chrome, however they do not appear under Internet Explorer or Safari (Windows).
As such, I recommend that you try viewing this post with Firefox. Actually, I recommend that you try viewing everything with Firefox!;-)

Sunday, October 18, 2009

Future of Portals?

What I found to be interesting in my research of portals and portlets are around where this technology will be in the future. The basis around this curiosity came from the article here: http://blogs.zdnet.com/BTL/?p=4912: “The future of portals is mashups, SOA, more aggregation”.

When I first started reading this the question that came to my mind is: “Will mashups replace portlets within a Portal?” We discussed mashups a couple of weeks ago and one of the questions posed at that time was will mashups replace ERP? (http://sysintteam.blogspot.com/2009/10/can-mashups-replace-erp-enterprise.html). After reading more about the topic of the future of portals I saw that really what the blog was proposing was that in the future mashups will be used to actually aggregate multiple portals together. Imagine being able to use a portlet within Google within your own company’s enterprise portal. I actually found an example here (http://blogs.sun.com/javacapsfieldtech/entry/healthcare_
facility_mashup_portlet_with)
where a company is looking to use what is called a ‘mashup portlet’ to leverage Google maps to show facility locations. Google actually provides their APIs at an enterprise support level, of course with the purchase of a license, so that companies can integrate a solution which is already proven to be some of the most popular tools (http://www.google.com/options) for personal and professional activities. In addition to the many advantages that this will offer companies there are also some concerns. Personally I think that one of the biggest concerns would be around security. Due to the fact that the different tools provided by Google are so popular, there is a very large audience that has ‘interest’ in them. With the API being available to virtually anyone this can pose to be a security threat to any company leveraging the tools provided by Google. However for one to be able to exploit the Google API they would have to first get past the security of the company’s Enterprise Portal. Nonetheless security should still be an important point considered when integrating third-party applications within a portal.

Saturday, October 17, 2009

Portal & Portlets

On Tuesday we will be discussing Portals and portlets with UI Integration as the focal point. With the initial research being completed I couldn’t help but notice that portal is definitely a buzzword with more uses than swiss army knife. If you doubt me…try typing in ‘portal’ at Google and see if you can find a word that returns more hits. But I believe despite around all the hoopla on the word portal…at the core of the word (in reference to technology) is integration. Portals allow for the integration of different applications to provide the end user one central location point for access. The applications that are integrated within the portal could also be referred to as portlets. Web Services for Remote Portlets (WSRP) a standard used for portlets will be discussed as well.

There are instances when a portal contains the full-fledged application integrated within the portal and then there are instances when the portal only serves as a gateway to the application. The two instances previously mentioned are defined as integration on an application layer or full integration and presentation layer or more of a shallow integration. The implications of these will be discussed in class.

There are some links for general reading of portals and portlets below.

Web Portal
Portlets
Web Services for Remote Portlets (WSRP)
MSDN: Portal Integration
Portals and Web services: Services at the user interface