http://blogs.msdn.com/b/crmnorway/archive/2011/11/03/dagens-g-228-stbloggare-p-229-l-andr-233-kj-248-niksen-fr-229-n-skill.aspx

Kjøpe ferdig eller lage selv?

Det kan ofte være vanskelig å beslutte hva som er den mest hensiktsmessige måten å implementere nye IT systemer. Mange leverandører tilbyr, mer eller mindre, nøkkelferdige fagsystemer som skal gi en rask implementering og gi tilgang til funksjonalitet som dekker de behov man antar at bedriften har.

Andre igjen tilbyr å tilrettelegge funksjonaliteten man, i samarbeide med kunden, har kommet frem til best understøtter selskapets organisasjon, rutiner og regelverk. Av disse finnes de som bygger systemet fra bunn av, basert på tilgjengelig utviklingsverktøy – og de som baserer leveransen på et rammeverk som medfører stor grad av konfigurasjon i motsetning til programmering.

Det er en vanlig oppfatning i dag at utvikling av systemer fra «bunn av» i de fleste tilfeller viser seg å bli for tid- og kostnadskrevende.

Vi vil derfor her konsentrere oss om å se på noen forhold som kan hjelpe beslutte om det vil være mest hensiktsmessig å anskaffe en kommersiell fagapplikasjon, eller å tilpasse løsningen basert på et tilgjengelig rammeverk.

Beslutning bør fattes ut ifra hvilket alternativ man tror best vil

· Gi selskapet et effektivt arbeidsverktøy

· Kunne realiseres på tid og kostnad

· Kunne vokse og videreutvikles i takt med bedriften

By: Geir Mathisen, Skill

Information Architecture

Before jumping into evaluating technology and functionality it is essential that one has a good understanding of the business requirements the organization has with regards to implementing new information management tools.

The best way to approach this is to build a high level “Information Architecture” for the organization. This can be done by breaking up the huge area of Information Management into smaller units that each

1. Cover an independent functional area.
2. Has relationship to other functional units in order to provide a consistent and integrated solution.

A company’s “Information Architecture” is then build by defining the high level business requirements within each functional unit, and guidelines on dependencies between units.

A framework for building a company unique “Information Architecture” can look like this:

Figure 1 – “Information Architecture” framework

The functional units that should be specifically mapped out related to business requirements are:

Storage

Involves looking at requirements for various types of storage technologies, in order to preserve information during the lifecycles defined.

Issues to rise are:

· Scalability requirements. Do we need a shared pool of storage that can be scaled and reused without affecting running operations?

· What databases to use, and how to optimize for the expected load.

· Do we have preservation requirements that require use of permanent storage media, like optical disks (WORM – Write Once Read Many). It so; what kind of storage systems do we need to meet expected response times (disk robots, etc).

Records Management

Deals with establishing how documents that were produced as part of a business activity/transaction should be saved, managed and preserved.

The governing rule, based on international standards, is that such documents are to be retained as “Records”. This implies storing them according to a predefined classification system, and in a way that prevent any changes or modifications to the document content.

Records should also be associated with a given “Disposal Rule”, which dictates its preservation time and end-of-life activities. Rules for migrating the document across various storage tiers (eg. DB à Disk à WORM) based on given criteria (last reference, creation time, document type, …) can also be included.

If there are legal processes going on that affects documents it can be required to place a “Legal Hold” on the documents to prevent any disposal activity to happen.

Other areas to investigate regarding stored records are:

• Requirements for digital signing of documents, and management of digital signatures and certificates.
• If final documents should be preserved in a fixed file format to preserve future readability. Typical formats used are PDF/A or TIFF. If so; should this format replace the original document, or be stored alongside the original?
• How is the organization expected to reuse stored records?
• Do we also need to register physical items (like paper documents) in the archive, and manage them according to the same rules as electronic documents?
• What audit information do we require to ensure company policies, and trace activity related to stored information?
• How should correspondence, in particular using email, be stored and tracked to business activity in the archive?
• Duplication detection for preventing the same document from being saved in multiple locations.

Document Management

Is about how we work with documents while they are still under development.

Involves defining the classifications needed to represent the various document types used throughout the organization. As part of this, looking at what metadata is required to ensure unique and practical identification of each document – for simple and intuitive location and retrieval by business users.

Documents can also be associated with taxonomies in order to associate them uniquely to their business relevance. Taxonomies are predefined keywords that represent various terms that give information on business relevance. Examples could be vessel name, office location, suppliers, country, departments, etc.

The main taxonomy tends to be the primary folder structure that is defined. The structure and nature of this should be carefully planned within each business unit to ensure that the filing structure visible to the end users is as intuitive and easy to use as possible. At the same time the structure need to support the business needs for all document types, as well as the defined management rules in a good way.

When documents are to be shared and worked on by several employees a security policy need to be defined to allow for this openness.

Features like versioning, locking and check in/-out are essential when working with documents, and the organization should plan for how to use these features in a consistent manner.

Today, many users are travelling between various office locations, as well as works from remote locations not connected to the company network. The organization should investigate their requirements for offline access to centrally stored documents.

The transition where a document moves into being a record is something to discuss within the various business units. Technically this tends to be a small change, where the document is given some new attributes. But this change need to be defined related to the business processes and procedures involved in document production, and made into a natural (preferably automatic) activity in the daily tasks of each employee.

Business Applications

Every company has a number of business applications that is being used throughout the organization to support the primary business. These are a variety and mix of standard enterprise applications like SAP, a CRM system, etc – and more specialized systems to support individual line of businesses. Business applications can be standard systems, or special made systems – with a variable degree of integration to other systems.

Related to an “Information Architecture” it is important that the requirements for integration between existing business applications and the components making up the consolidated information platform is well defined.

Typically this includes requirements for documents produced within business applications to be stored and managed by the document archive, and at the same time give access to centrally stored documents from within the business application.

There might also be requirements for a workflow tool to access and store information directly to business applications, and for a search tool to include information from business systems.

Workflow / BPM

Workflow or Business Process Management (BPM) is used to streamline the way repeatable business processes are executed throughout the organization.

By modeling the sequence of activities that makes up a given business process and assigning the rules that control the flow – a workflow server can monitor each execution of the process and make sure all actions are performed according to the business rules embedded in the model. Typical rules that make up a process definition are:

• Users or groups of users to participate at a given stage in the process.
• User interface rules on information to be given to, and requested from users at given stages.
• Expected response times for task assigned to users.
• Escalation actions when expected response times are not met.
• Key performance indicators (KPI’s) that contain key information about the running processes.
• Integration with external systems applications that provide or receive information from the running process.
• Exception handling

In order to optimize business processes “Simulation” can be added to test a given process model in various operational environments. In addition to feeding live data from the running environment it is possible to vary workload, available resources and task response times to get a feeling for the scalability and potential for improvements in a given process.

Collaboration

Collaboration spaces are used to collect pieces of information that has common business relevance, and present these through a central interface. Typical information types to be included are documents, calendars, contacts, news lists, task lists, discussions and links to information contained in external systems.

This information is collected in team rooms, given a common look and feel and presented to registered users through a web interface.

Team rooms should be used primarily as containers for tasks that are limited with regards to time, participates and scope of work. Typically projects. When the work is completed the team room should normally be shut down and removed – with information being moved to the archive and managed as records for future reference and management according to the company retention rules.

Collaboration spaces can also have value as more permanent structures. This can be as information exchange rooms for smaller departments, for given products or as individual playgrounds for each employee.

Search

The search mechanism is a vital component for retrieving information, and as such need to reach into all the various components that make up the “Information Architecture”. Most search tools do this by indexing the various information sources in use, and provide a search interface that spans across everything.

Search should be organized in two flavors:

1. Simple search – that searches across all content and metadata for the given word(s).
2. Advanced search – that allows for search only in individual systems or data types. All metadata and taxonomies defined should be available for specific searching – also in any combination.

To improve usability it is common to predefine some search strings that is of general use, and make these easily available to relevant users.

It is vital that all security settings throughout the infrastructure are honored by the search engine when indexing information. A user should never be allowed to locate information through search that he/she could not access from the underlying system directly.

Clients

Client applications are the interface between users and the products that make up the “Information Architecture”. In most situations there will not be only one client application available for accessing this information. To make information flow as smoothly as possible through the organization it is important the make documents and relevant functionality available to business users in the client environment they are currently using and are familiar with.

This requires integration into standard office applications like MS Office, email clients, web browsers, but also business applications like ERP/CRM systems and in-house line-of-business applications.

The bigger picture

Figure 2 – "Information Management" as part of the overall architecture

When building an “Information Architecture” it is important to also give thought to the more general environment in which the information platform will live

In particular there will be some dependencies with regards to the IT infrastructure already in use. Typical areas to consider are preferences to operating systems, databases and other SW components that make up the server backbone. Tools and procedures for securing data and recoverability need to be taken into account, as well as platform preferences that can be vital for achieving good integration between components.

If an overall security policy exists within the company, this will give important guidelines to how the “Information Architecture” should be mapped out.

And of course, the general company policies will have to be taken into account as well to make sure that the “Information Architecture” supports and strengthens the business in general.

Value-add

Building a consolidated platform for information management will have a number of organizational benefits, and enable the company to focus on its key business.

Some value-adds to look for are:

• Reduced manual operations
• Increased throughput in communication
• Improved control over running activities/processes
• Improved quality in document production
• Improved access to information
• Improved internal and external customer satisfaction
• Reduced load on key resources
• Improved security
• Reduced system management and support
• Improved compliance with quality standards
• Reduced email traffic and storage

Next Steps

It is recommended that each organization spend some time in defining a high level “Information Architecture” before moving into evaluating technology and products for their document repository requirements.

The goal of this work should be:

1. To better understand the various procedures and tools currently in use throughout the organization
2. To better understand the bottlenecks that prevents efficient information management today.
3. To engage key people in the various business areas and raise the awareness and their focus regarding how to improve information management within their business line.
4. To establish a company vision for information management.
5. To define a core set of requirements that can be used as a base for evaluating technology and vendors.

During previous implementations typically many of these issues were addressed. It is recommended to use the material from these projects as a starting point for the consolidated “Information Architecture” to be defined.

Any existing quality certificates (ISO ++) should be used actively in this work, as they will contain information on many topics that need to be looked into. Given that these documents are up to date they should be able to provide details about

· The current business processes in use

· What documents are being produced as part of the business process?

· What reports are expected?

· Which users and functions have document responsibilities?

As these processes are known to employees new tools based on these will reduce the training requirements and the “fear factor” related to introducing new technology and procedures into the organization.

Startup activities

1. Ensure management commitment

2. Build company security policy

3. Define main document types

4. Define document preservation rules

5. Model key document processes

6. Use of e-forms as communication tool

7. Define reporting requirements

8. Define vision for information exchange

Risk assessment

As this phase deals solemnly with mapping out information from within the organization the main risks will be around getting access to key people.

If external resources are to be used as advisors in some activities, there is a risk involved with getting access to quality people – and have them available according to the project plan.

As with all internal projects there is a risk that business priorities are made that conflict with projects plans, and delays activities.

Nysgjerrig på hva nettskyen kan gi av fordeler for deres virksomhet?

Nettskyen er uten tvil et hett begrep som mange i og utenfor IT-bransjen snakker mye om. Men hva er egentlig nettskyen? Er nettskyen kun en hype, eller er dette noe deres virksomhet kan dra nytte av?

Microsoft er «all-in», og en av de aller mest aktive aktørene innenfor nettskyen. Microsoft satser store deler av sin virksomhet og mange milliarder kroner på nettskyen. Allerede leveres flere verdiøkende løsninger fra Microsoft sine gigantiske datasenter. Office 365 er Microsoft sitt nettsky tilbud for produktivitet og samhandlingsløsninger basert på Exchange, Sharepoint og Lync.

Office 365 er nå lansert, og mange virksomheter har allerede implementert tjenester fra Office 365, og mange flere er i test. Tilbakemeldingene fra disse virksomhetene er meget positive.

I samarbeid med Dell holder vi “Office 365 – i teori og praksis” lunsjseminar på Tjuvholmen Sjömagasin, 22.september kl 13:00 – 16:00.

Mer informasjon >>

1. Direct Access gikk ned med en gang jeg forsøkte å koble opp mot servere i Skill.
2. Etter alt fra 2-10 dager sluttet all webbrowsing å fungere og jeg måtte kjøre en kald restart av router for at ting skulle fungere (kom ikke inn på routerens web grensesnitt en gang).

Etter mye søking etter løsninger kom jeg til slutt over en artikkel som virket lovende. Mange sleit med samme problem så lenge DNS relay var enablet på D-Link router (denne er default enabled). Jeg gikk inn og disabled den på routeren og etter dette har faktisk Direct Access fungert stabilt i ca en uke. Jeg har foreløpig ikke hatt problemer med webbrowsing heller, men trenger nok litt mer tid før jeg bekrefter at dette også er løst.

Kan det virkelig bety noe for resultatene i prosjekter hvor deltagerne sitter og jobber? I dag har man jo tross alt alle muligheter for et godt samarbeid uansett, med bruk av videokonferanser, Lync, etc?

Ja, jeg mener det har en betydning. Alle mulige hjelpemidler kan ikke erstatte helt den gode effekten av fysisk nært samarbeid. Og min påstand er at man jobber best i prosjekter når man sitter i umiddelbar nærhet av hverandre, gjerne i ett felles kontorlandskap. Påstanden bygger jeg på egne erfaringer fra mange års prosjektledelse, hvor jeg i det ene ytterpunkt har ledet prosjekter hvor de fleste sitter i hver sin by i Norge, til prosjekter hvor hele prosjektteamet har sittet sammen i ett kontorlandskap.

Hvorfor ta opp dette? Er det ikke noen alle er klar over, at vi kommuniserer best når vi er fysisk nær hverandre?

Jo, helt sikker, men jeg mener at dette med samlokalisering blir for lite vurdert i etablering av prosjekter. Rammeverk og metoder for prosjektgjennomføring er selvfølgelig viktig, men det er store fordeler ved å jobbe samlokalisert og man bør i det minste vurdere dette i fm. etablering av prosjekter.

Hvordan tenker du for å få til god samlokalisering?

For å få til dette på en god måte er det en fordel med ressurser som kan bruke tilnærmet 100 % av sin tid. Dette er vanligvis lettere for leverandøren å få til enn for kunden. Representantene fra kundene har oftest linjeoppgaver som ikke kan overføres til andre.

Gjennomfør prosjektene på kortere tid, slik at arbeidet blir mer intensivt, da er det letter å få til dedikerte prosjektdeltagere. Da kan også prosjektdeltagere som bor langt vekk fra hovedsetet til prosjektet letter få til f.eks. pendling med overnatting etc.

Bruk prosjektdeltagere som er lokalisert i nærheten av hovedsetet for prosjektet.

For noen prosjekter er dette selvfølgelig helt umulig å få til, men det lurt uansett å gjøre en vurdering i forkant. Man kan alternativt finne enkelte ukedager hvor flest mulig kan samles.

Kan du si litt om hva du mener konkret er fordeler og ulemper med samlokaliserte prosjekter:

Fordeler:

• Det gir en bedre teamfølelsen, det styrker følelsen av at man jobber i ett og samme prosjekt for å oppnå et felles mål. Eierskapet til prosjektet vil øke og man vil oppleve at man sammen med kunden jobber dedikert for å få til en best mulig leveranse i prosjektet. Man bygger ned barrierer.
• Gjør det letter å ta raske beslutninger, man trenger ikke vente til f.eks. neste statusmøte.
• Man blir godt kjent, man er jo sammen hele tiden, og ikke bare i møter.
• Prosjektleder kan lettere følge med på hvordan arbeid blir utført, og hjelpe deltagerne i å få prioritert og utført prosjektarbeidet på en riktig måte.
• Prosjektleder ser hvordan deltagerne jobber og kan bidra til å legge forholdene til rette på en bedre måte.
• Lettere å få til et samarbeide på tvers av fagområder og med det løse utfordringer på en bedre og raskere måte
• Når kunden er med i samlokaliseringen får man en utmerket samhandling.

Ulemper:

• Har man prosjektdeltagere som ikke går godt sammen (for det skjer jo) og det ikke er mulig å gjøre et bytte, så vil det muligens være bedre at man ikke sitter sammen.

Fordeler ved ikke samlokaliserte prosjekter:

• Som for ulemper ved samlokalisering. Har man prosjektdeltagere som ikke går godt sammen og det ikke er mulig å gjøre et bytte, så det muligens være bedre at man ikke sitter sammen.

Ulemper ved ikke samlokaliserte prosjekter:

• Dårlig kommunikasjon som kan føre til kommunikasjonssvikt, som kan resultere i dårlige leveranser i prosjektet.
• Kommunikasjonen kan bli mer formell og man fanger ikke opp viktige nyanser, dvs. skriftlig pr mail etc.
• Det kan resultere i med administrasjon, det krever mer av prosjektleder å holde gruppen samkjørt
• Dårlig tilhørighet til prosjektet.

Og til slutt, hvordan kan man i ikke samlokaliserte prosjekter øke samarbeide?

• Daglige korte statusmøter (15 min) hvor hver enkelt pr tlf eller video rapporterer inn hva som er gjort foregående dag og hvilke planer man har for dagen.
• Ha en god felles prosjekt-web som alle må være flinke til å bruke og kommunisere via.
• Etablere en felles forståelse for behovet for dokumentasjon og etablere god tydelig dokumentasjon
• Etablere gode elektroniske samhandlingsrom der man kan “virtuelt samlokaliseres”, for å etablere felles informasjon og diskusjonsrom.

Lykke til

Ved hjelp av onload/oncscript og FCK editor har kjedelige ntext felter blitt til felter hvor tekst kan formateres og lenker legges inn. Det fine med denne løsningen er at formateringen lagres og kan tas med videre i workflowen, på den måten ser  teksten i den automatisk genererte e-posten like fin ut som teksten lagt inn i WYSIWYG editoren.

Ta kontakt om du er interessert i denne løsningen så skal jeg dele den med deg!

I tillegg har de kvittet seg med MOM 2005-agenten…
Skill har allerede gjort en stor installasjon av FEP 2010 RC, og ser frem mot flere oppdrag rundt antivirus på server/klient!

Denne uken har vi signert leiekontrakt på nytt spennende bygg for vårt Østfoldkontor! Bygget er under oppføring ved Science-senteret på Grålum og eies av Infotjenester.

Bygget skal stå klart til 1. april 2011, hvilket betyr at vi håper å kunne flytte inn til påske!

I tillegg til Skill, som skal inn i en del av 1. etg, skal Infotjenester selv ha 2. og 3. etg., samt at PwC skal inn i 4. etg.

Vi håper og tror at dette blir et skikkelig løft både for ansatte, kunder og partnere.

Ved å aksessere CRM via agent URL’en fyres klienten igang og innkommende og utgående CRM samtaler (tale eller IM) foregår i CRM.

Den som ringer inn sitt kontaktkort slås automatisk opp når jeg aksepterer innkommende samtale:

1) Melding om innkommende samtale via lyd og melding nederst i høyre hjørne:

2) Kontaktkortet til personen vises automatisk og man har egen knapp for å lagre en aktivitet (typisk logge telefonsamtalen) direkte fra klienten. Her er det også mulighet til å enkelt legge opp egne knapper/funksjoner tilpasset den enkeltes behov.

Ja, dette gleder vi oss til å vise kundene våre!