Intranet and portals - coexistence or consolidation ?

[JoergWolf]

Hi,

as intranets typically center around HTML pages and documents, they offer a valuable source of information that should also be available via a portal (e.g via the integration approach for documents that is provided by the KM platform).

However, if you talk to people, they very often have a clear distinction between a portal (this is more application driven e.g. via integration of business systems) and an intranet (HTML pages, documents as said above).

I would like to get some views on how you the connection between portals and intranets is seen by the group in this forum:

Will intranets (and web content management applications) gradually merge into the 'Super-Portal' or will they continue to exist next to each other with more or less sophisticated integration mechanisms ?

Cheers,

Joerg

[Former Member]

Hi Crew,

There are so many dimensions to the question is difficult to know where to start...

As a naive answer you could say that Intranets are similar to in-house developed legacy systems, and the Portal is similar to a commercially produced ERP system, in terms of progression...

If you wanted to use the Portal to replace your Intranet, you would fragment your Intranet into its most granular form... Remove navigation links from pages... Populate the Portal with the fragmented content...

The Portal in it's present and future form is the evolution of the Intranet and applications...

In simple terms, the intranet will become content for the Portal because it just does not deliver the same functionality for the same amout of effort, cost, and time...

Regards

Paul Chambers

[markusriedinger]

Hi all,

If we take this discussion on a level higher, not talking too much about document or applications, but about the information, which should be transported to a user, one will see, that only the Use Case is different. In a Portal both (application and documents) are using a "document" container to transport the information to the user.

The Enterprise Portal Content Management uses Repository Managers to deliver Information in Documents from various sources. (Mail, Web..., web content,) or even from non document sources like users. This Repository Manager then delivers information about a user in a document container (like a business card).

Since CM offers a wide set of services on those "documentes" the user is able to extract/find the information from the documents faster (e.g. search, rating, discussion....).

The Portal Content Directory on the other side delivers information to the user mainly from application sources, by structering this applications in "document" like containers (Pages, iViews)

Since The Portal Content Directory is able to deliver this Information "User Centric" (Role based) the user is able to get infomormation for his tasks faster and more relevant.

Why not help the user in allowing him to use the additional services CM is offering for "documents" beeing iViews/Pages. wouldn't it be usefull to search or rate a portal page or having a discussion there???

Why not having a Repository Manager for the PCD?

On the other hand side would't it be nice to be able integration CM Documents "user centric" inforamtion delivery of the PCD. E.g. a CM document could be a PCD iview strait away without having to manually create it? this way a Content Admin can search or navigation to such a document and add it to any portal page, without hassle.

Cheers,

Markus

[David]

Hi Markus,

Good to hear from you!

I agree that it would be great to have CM functionality in the PCD area. I really like the idea of having discussion capabilities. A good example is for typical (and sterile) everyday application type areas such as Accounts Receivable invoicing where a posting clerk could open a discussion with several people involved with a delinquent account.

Also, the ideal of PCD abilites in CM is great. It would give us a kind of "push" capability for specific documents that are of keen interest to particular roles. Something like a person can do for themselves in Kanab now, but preconfigured for them based on their role.

Best Regards,

Dave

[frank_albrecht]

Hi guys,

do you think it would be a good idea to offer each document as an iView (with e.g. an edit button rendered on the screen for the authors) ?

Should it be a self service for the user, like save search as iView we could offer "Save document as iView ?" Then we create a copy of an html-preview iView which will contain a link to the document (as iView parameter).

What do you think ?

Thanks Frank

[Former Member]

Hello Everyone,

Looks like I am the first non-SAP guy involved in this thread, and it has been a while since the last post so hopefully you guys are still tracking the forum.

I totally agree with some earlier comments that smaller departmental portals will be absorbed by larger more enterprise portals, which encompass functionality at an enterprise level. In the early days of the portal effort people were build repositories which focused on putting only textual content in HTML form into a search-able web application. Then came the introduction of role-based security along with the optimized storage of un-structured content (i.e. Documents, Word, PDF, Scanned Paper images).

It has been proven that these 'non-text' documents hold a majority of the value within a corporation. So it is important to enable an intelligent method for making sure people can utilize these pieces of information when needed.

One of the things that FileNet discovered early in the content management space was the importance of presenting users with content needed to make decisions without requiring them to go an 'search' for content. One of the ways we do that is with our business process management tool which allows people to access their personal in-box within a portal and be presented with content needed to make a decision on a specific piece of work.

For example in an Accounts Payable solution, AP clerks open their portal and are able to see what work they have in their in-box. They open up the first item and they are presented with a scan-image of a paper invoice that was faxed into the company. They are then able to determine if the invoice should be paid. If it is they can enter the information into SAP directly from the portal. If not they can re-route the invoice for proper approval. All of this without needing to jump into different applications or even logging into different applications.

Are you guys seeing the same thing?

Thanks,

Craig Gutjahr

FileNet

[David]

Hi Joerg,

In the US we call that 'Opening a can of worms".

I feel as if the super portal is already here today with the SAP Portal product being one of the premier examples.

If I may, I'd like to reflect on some of my own experiences.

The distinction you made between the two areas of Application interface and (what I would call) the KM area seemed more appropriate to the state of technology in the early and mid 1990s. This is when some software giants like SAP and Oracle started to put GUI front ends to their former character based ERP systems. In doing so, they introduced a customizable front end that was designed to present a slightly different "face" to the user based on their job. While there was a considerable expense and effort up front, once in place, it was relatively easy to use. However, the repository capabilities, even for financial reporting, was limited.

At the same time, many in house IT departments began to experiment with creating simple repositories for their most important documents and reports. However, we found this to be highly labor intensive requiring a lot of html and perl effort to maintain since linkages to specific documents was done by hand.

In the end, we were still left with multiple icons sitting on the Windows desktop for different purposes.

With the advent of true portal products, we have the marriage of both worlds in a far less labor intensive scenario. The integration with various ERP systems takes time, but the will eventually be perfected. The KM capabilites of portal products is also maturing and is far more robust than anything I or my collegues thought possible back then.

Best Regards,

David