Re-implementation to SC5
We are planning to re-implement our SC5 environment from SC4.09 - we have a lot of customizations, data to transfer and connect.it scenarios that need to be accounted for.
Has anyone tackled a fairly complex upgrade via the re-implementation method? :wink:
What are the most important tips?
How long did it take?
Any information would be appreciated.
Regards,
InspectorGadget
Have You read this
http://www.sc-resources.net/viewtopic.php?t=18041
Thanks Tommy,
I did take a look at the information you posted, we are implementing onto the same platform. Could you point to what specific points in your posting were MVS centric (if any) or if all lessons learned would be appropriate to re-implementing from Unix back onto Unix?
Any thoughts would be good.
Regards,
InspectorGadget
Russel,
Will give you ALL the answers in a few months ( I hope...) :wink:
The platform should not matter. When reimplementing I would still use same approach even if both source and target system was running on the same os.Originally Posted by InspectorGadget
Hi all, I kind of made a joke when I responded to this item. Russel thanked me for my input on a very polite way... thank you for that!
InsprectorGaget (liked that, does anyone remember SportBilly, or BananaMan, or even better, these days, is a fan of 'Cow and Chicken' and ofcourse Johnny Bravo 'Man, I'm pretty') So funny!! I even have a Johny T-shirt yelling that :wink: (never wear it to work of course;-)
To get serious, here's my respond to Russel, in order to get the discussion here, where everyone can help out or maybe learn;
"Russel,
How nice of you! In fact I was only joking when I wrote that reply! Not that I don't want to share things, I certainly will, even if it was only for some help at the sc-resources site!
I'll post some thoughts and things later, Tommy already explained a lot of things, which were helpfull for me too. It's a hell of a job... THINKING about it, especially trying to NOT make the same mistakes again , takes most of the time....and new things in new versions... it's hard enough already, but when for instance you see the whole security is kind of up side down via the operator record, you have to get familiar with, and get used to *that*, and before you know it, the day has passed. It sure takes a lot of time....
Let me know where your stand, and what your plans are with your re-implementation...."
Well, to make a long story short, althuogh there are a lot of ideas, we are still *thinking*about thing most of the time! Anyone doing the same thing, help out here!?
Hi,
You are saying that you have a lot of complex customization to move - I guess the reason for re-implementing instead of upgrading, is to get rid of some of the complex customizations :wink:
If your system has been alive for years, I will suggest you do the following before you start.
Look closely at each module (SM; IM; CM; ICM ) and identify where OOB funtionality from 5,1 can replace your customizations.
Dont look at field level but look at process level. When you first implemented SC, it problably replaced an old system (eg: Infoman), and you problably have functionality left from that time that is obsolete now !
Then start with a "clean" OOB 5,1 system, and build an Alpha version.
-Move core data (Contacts, company, dept etc. not from the old system, but from the data sources)
-Build new forms (+links & FC) from scratch, instead of using the OOB or your old forms. Focus on "as few fields as possible".
-Keep the alpha version simple - Dont move old "Rocket-science" if it doesnt add business value :wink:
Then evaluate the alpha version, and document where it has to be improved to serve you needs.
One of the important tasks is to evaluate dbdicts. Since version 4, Peregrine has added way to many fields and arrays to the OOB system :roll: , and I will recommend that you remove all uneccessary fields from the data tables (probsummary, incidents, device etc). Pay special attention to arrays. If your system system is running on RDBMS you will get between 20-50% better performance if you can decrease you dbdict fields by 50%.
As for moving data from the old system to the new one:
If you are on RDBMS and have a huge amount of data - Move on RDMS level for large tables.
If in P4 - You may have to move some of the data with triggers:0 to avoid problems, and then manually udate active records (open calls, incidents etc.) to make them work.
Most important - Keep your new system simple, It will make it easier for the users to use the system correctly, and it will make you work easier in the future.
To everyone who has posted information - it's all great and gives me a little piece of mind on what to expect when we go to re-implement. Yes, we do have a fairly complex environment - over 70K employeed, incident management, reqeust management and some use of ICM as well as integration between incident and adjacent systems like our paging servers and enterprise management. Lots of things to consider, lots of data to move. I've also been on to Peregrine for help with this info but what you have provided so far has been excellent.
Thanks again...
Regards,
InspectorGadget
Hi all!
officially we start re-implementing to 5.1 from september 1.
We will go into production in FEB next year, not because it will take us that long, but we have to consider other projects also ( NT to XP, Asset Center, Introduction of Ethernet and other thing which will take time of the same resources we need...)
Will try to keep you informed here!
Please take into considiration; we will use JCube's Intraflow here, so not all we do will work out for others. Some of the problems mentioned in this forum, i do not answer to or think about, since I know using IF will not give me this problem to think about. On the other hand, *all* that is done by IF, can be done in SC.... I am just not the right person to ask! ;-)
If any Sc5.1 related things come up, I will keep track of it right here!
Also, we are in the middle of a reorganisation, so no plan or person is secure on this moment...
Maggie,
good luck with the re-implementation - there is some good stuff already posted and when I compared notes to what Peregrine was telling me there were some mis-matches. I have already informed Peregrine that they need to do a thorough and accurate job of gathering lessons learned / best practices of re-implementation for publication on their website. I have also asked that this be delivered in the forum of a user group meeting. Anything I get (that is accurate) I'll forward on to this forum. We are planning re-implementation for early next year (but I am beginning my research early so that we are better prepared and make fewer mistakes). 8)
Regards,
InspectorGadget
Russel,
Thank you for the reply, let's join forces here, I know I will be inventing the wheel again starting Sc5... saw some thing already.... something easy turns out to be very hard, or a bug is still there! Even if it is a small thing, it should still be mentioned... could save some hours of thinking and doing... well, it is Service Center!
:cry:
Russel,
Wondering.. what have they told you and where is the mismatch??
Here are some examples:
Q. For records being transferred to new system, does order matter?
PGN answer: No
SC-Forum: screlation active fields should be transferred AFTER related records (or else the fields appear like they were set randomly)
Q. What types of records should be updated manually?
PGN answer: None
SC-Forum: Change records required manual transfer for approvals to be set correctly.
Q. What are the most common errors encountered by customers during re-implementation and what were the solutions?
PGN answer: No true answers
My response: Unacceptable, there must be some errors and known solutions!
Regards,
InspectorGadget
I just received some info from Peregrine - a web cast on ServiceCenter upgrades - nice that they gave me this info at the last minute!
The details are as follows:
To listen to the replay: (888)203-1112 or (719)457-0820 passcode: 224350
Available through Friday, August 29, 2003
http://www.peregrine.com/us/Company/...radeReplay.htm
remember that for overseas participants, use the 719 area code phone number, preceded by the country code (1) for USA.
Hope this helps out!
Regards,
InspectorGadget
Right! and august 29 is tommorow!? Hmm...
I just dialed in and looking from a reimplementation point-of-view, I didn't find it highly interesting (and yes, I'm aware that the subject was upgrade and not reimplementation :roll: )
Best regards,
Michael
Just some info here about our reimplementation; we have a 2 months delay, we will not start before begin of november (officially).
So it's not a matter of not posting experiences here, we just have not started yet...
But have to say; the more i read and see of 5.1, the more I worry. Not alle because of bugs or (new) shortcomings, but also because of seamingly minor things that can have major consequences.... I think we will need more time to discuss and investigate sc5.1 then planned...we have to be carefull not to underestimate it!
Hope to have some usefull things soon...(who knows, maybe this was the winning tip :wink:?)
Re-implementation
Maggie,
Good luck for the start of the re-implementation.
From my reseach, the time for re-implementation typically includes around 50% for preparation, 40% for re-implementing the actual application / business rules validation tailoring / data transfer and around 10% for miscellaneous activities - server environment, installing software, calls to tech support, testing etc.
ServiceCenter 5.1 has done a better job with ICM and introduces a wizard tool. I'm going to try and find out more on its "n-tier" architecture capability but I believe it is capable of multi-instances of ServiceCenter that point to a common data respository (for a more distributed model). This is probably useful for load balancing and from what I'm told, failover capabilities at the application layer.
I just completed my ServiceCenter introductory class last week, so its all starting to make more sense to me now!
I got a sneak preview of ServiceCenter 6.0 alpha during the week - its all web-based screens, has an explorer-like navigation pane that allows you to go between tools, dbdicts, formats etc more easily (rather than jumping between screens or needing to keep multiple instances open). The backend has an XML SOAP processor included (might be useful from an EAI perspective) - no actual details on that yet though.
Regards,
InspectorGadget
Hi all,
Could use some advise here....
In the process of planning the upgrade, reporting became an issue.
Scenario1 (seems the easy way, but I doubt it eventually):
Keep old data in SC4, use Crystal 8.5 to report (odbc driver 4)
New data in Sc5, Crystal 9 (odbc driver 5)
Worst case: if both Crystal's or odbc drivers have conflicts, use them on seperate machine (one reporting on old data in SC4 , one reporting on new in SC5)
Hearing and reading about all the trouble people have with the odbc driver and Crystal, this seems like a cheep and eventually useless configuration.
Scenario2 (probably more time needed to implement, but will pay off quickly, in my opinion):
Leave the Sc odbc driver for what it is...
Put some effort in merging SC4 and SC5 data in a datawarehouse (RDBMS of any kind), or some verdor solution doing the same.
In our case; we are a Bussiness Objects oriented company... leave Crystal also, use BO (although the SC odbc driver is the real issue here, and the fact data being in both SC4 and SC5 database)
Any thoughts? What are you guys doing over there????
Anyone has as succes-story to tell about the combination of using 2 SC odbc drivers and two versions of Crystal Reports?
And do you really need to be on CR9 to report on SC5, or not (I seem to remember reading it, but am not a 100% sure)
All input is welcome, would like to know what the best solution is before we start anything. I am in favor of scenario2 but could use some backup here!! Might as well missed something that makes scenario 1 looks less bad as it sounds.....
Thanx in advance!
Maggie
Scenario 2.
We have designed a DB2 database which we export data from SC to. We started that with SC3 and now get data from SC5. Currently it is not all data just some summary data.
We are working on shadowing the relevant files and then replicate from the live DB2 shadow to a reporting DB2.
I look forward to the day we have this in place so I can throw the ODBC drives to hell!
Forget about getting 2 ODBC drivers to co-exist. Just to get one to work is a pain in the butt. Currently we have a ticket open with Peregrine that deals with 3 or 4 different issues regarding reporting on the structure parts and labor in probsummary.
As for CR9 that was also my impression. But I just got a firm commitment from Peregrine Support that the ODBC drivers from SC5.1.x is supported with CR from V7 and up.
Thanks Tommy,
I remember we discussed this subject before, but could not find it any more (or.. not quick enough;-).
Weird enough, our company had some trouble finding a company to act as a "referential site' to discuss/exchange experiences etc...
Would you, or your company, be willing to do so, if needed?
Anyone alse for that matter, any dutch company guys reading this? (hint!)
Our idea is exactly the same (discussed this, also..), shadow on db2 for reporting purposes. Getting rid of odbc driver etc.... all the same ideas.
If my company needs more assurance on this matter (except for me and two technical guys form Jcube are stating, is it ok to contact you?
hmmm.... that doesn't make my case any easier, but fair enough... if it works. Tried this also, can anyone confirm??? And SC odbc5 can read SC4 db, I presume??? or ....?
Sure. What we have is actually a sort of datamart that combines data from SC and our phonesystem Aspect to provide KPI information to our helpdesks. Based on the information from both systems a lot of calculations are done and special reports are published on our intranet.
If needed I can get You in touch with my boss who is the one that knows everything about our solution.
Peregrine say something to that effect but I would not trust that. We have killed our SC5 a couple of times by using SC3 ODBC driver on SC5 server - so I would not do any cross version without intensive testing. And testing may not be enough because our problem was caused by the amount of data, up to a certain point it worked but after that the server crashed.
Thanks for the info (and cooperation)! Will discuss it tomorrow at work and get back to you!
In a recent webcast from Peregrine, they heavily emphasized using OOB as much as possible. REvisit all your process and trim customizations as much as possible. A customized solution is not a canned solution.
There are currently 1 users browsing this thread. (0 members and 1 guests)
Posting Permissions
Reply With Quote
Bookmarks