[Barry FXW]

This is my second Monday on the job at a multiple site private school that
migrated from 6.5 RE+ EE+FE managed by "Academy Manager" to 7.6 w/o Academy
Manager back in October and are having more than a few"issues."
Looking for database management expertise in the education environment
locally (No. IL, So. WI, No. IN).
Lots of RE and FE resources but they don't cross over to the EE application much if at all
Barry FXW

[Haslady]

Barry - This is my 3rd Monday on the job, also a multiple "campus" private school, also running EE 7.6 also with "issues". I'm contemplating how to approach data "clean-up" in preparation for integration (which we're no where even close to ready). I don't have database mgt expertise but do run the same software and am sitting in Cincinnati, OH.

Have you been able to make much progress since March?

Jane H

[Barry FXW]

Jane Haslem,
We have just todaY COMITTED to do Registrar.
Karla Coop in Atlanta has emailed me repeatedly and we've spoken on the phone.
We just hired a good hand with RE experience and are confident he brings the vim, vigor, and alacrity to get all our little and BIG Blackbaud black sheep back in the corral.
My advice is to get a hands-on consultant from somewhere to drive the integration.
They didn't do it here, before I came, and suffered mightily. DATABASE MANAGER is a serously key role here now.
Front end of the data base is Admissions. Get the front end right and keep it maintained.
Online applications are great.
Student billing especially troublesome due to multiplicates of same names different addresses, different sibs, same dad -different mom, etc.
Still looking for a local EE consultant but Karla Coop is only a few hours away and all of them can with permission remote access to your desktop for "as you see it now views". I do this with my FE consultant.
Keep in touch.
I'm at Frances Xavier Warde in Chicago.
Frances Xavier Warde Schools
What school in Cincinnati, OH?
Regards,
Barry

[Haslady]

I'm at Cincinnati Hills Christian Academy. (Cincinnati Hills Christian Academy)
We're not anywhere near integration yet. I need a methodical data "clean-up" within EE first. I'm trying to discover how all the tables are used between the different modules (i.e. AO-RO-SB-RE). I imagine at most schools like ours, Development is a separate from Admissions and separate from scheduling and separate from Student Billing. An obstacle to full integration is figuring out who I need to get to agree on what. To tell me “Organization Type” is shared between SB and EE doesn’t tell me in what context …. Is it an issue that involves just Admissions + Student Billing? Does that affect my HS Guidance Office since we could be talking about the colleges that recruit on my campus? If I can lay out where a table is used and in what context (i.e. what screen you enter it on), I can spend my time getting the right folks to the table to make the right decisions and move on. Any ideas?

[kcoop]

I am not a Billing guru, but from what I can see on my test databases (version 7 and up) the integration to Billing is seamless (apparently after a merge is done- there is a knowledge base topic on this in the Blackbaud foruml), there are many interrelated records (such as Organization) as well as Tables (such as applicant/student status). You may find that when you click on Organization in Billing, there are several tabs that are specific to billing for that organization, but if you click on EE, the organization record will not contain some of those tabs. Admissions student records are called Applicant records and when you "enroll" the applicant you will then have a student record as wel as an Applicant record that is seamless and updates in the demographic areas. Again, you will have tabs of info that are in Applicant record that are not available in Student record. I have also found attributes do not transfer in some of the areas in the record.
You should be able to view as a supervisor all the various modules by selecting the drop down option under the Top Tool bar (next to your school name). If you are not able to access these, then I think your security set up needs some review. The best way to test this is to look at the records and tables in each of the products. I would also request a document from Blackbaud on what is related. My experience in the software industry tells me that they should have this available somewhere as their developers should have spec docs that they used to program from.

RE, however, does not have a seamless integration and I am not sure about the other products you mentioned. The integration of RE and EE is a recent addition and requires some clean-up/set up that Blackbaud documents will walk you through and can be quite time consuming. One of my clients did accomplish this last year and I am going to get it out in the open, we still have some issues with this and it is hard to figure out if it is the integration process or if it is the way we have data stored. Lots of calls to Blackbaud about it. There are also so many fields that do not populate RE that would be very helpful to have when the sync happens. At best, you can add new records to RE and they are then linked to the records in EE and when you schedule your syncs you will indicate your source system and the records are updated. This is where procedures are important. We have found some very unpleasant issues however (parents divorce or die) and the impact it has in RE (usually duplicate records, but it renamed a divorced mother with the stepfather's name in RE after the sync.. never got a good answer as to why from BB).

It appears that you have already upgraded and the merge probably happened already. From what Barry has said, they are now dealing with multiple records. Reviewing duplicate records might help and then cleaning up from there.

Hope this helps a little.

Karla Coop
KDC Technology Partners

[Tom Evans]

Quote:

Originally Posted by Jane Haslem

I'm at Cincinnati Hills Christian Academy. (Cincinnati Hills Christian Academy)
We're not anywhere near integration yet. I need a methodical data "clean-up" within EE first. I'm trying to discover how all the tables are used between the different modules (i.e. AO-RO-SB-RE). I imagine at most schools like ours, Development is a separate from Admissions and separate from scheduling and separate from Student Billing. An obstacle to full integration is figuring out who I need to get to agree on what. To tell me “Organization Type” is shared between SB and EE doesn’t tell me in what context …. Is it an issue that involves just Admissions + Student Billing? Does that affect my HS Guidance Office since we could be talking about the colleges that recruit on my campus? If I can lay out where a table is used and in what context (i.e. what screen you enter it on), I can spend my time getting the right folks to the table to make the right decisions and move on. Any ideas?

Jane,

Blackbaud's got some great pre-conversion checklists and documents on their support site which are helpful in understanding what is mandatory & required to be done before the AO\RO + SB conversion\integration and what will simply cause duplicate records and combined table entries which will not prevent the conversion\integration from running but will give you some messy data

The overall picture is that in 7, AO\RO and SB share the same database and RE keeps one to itself - there is still fairly seamless transfer of graduated students to RE as new constituent records. Basically the only table that HAS to be synchronized (as far as I have seen) is the “Grade level Now” table between SB and AO\RO. Entries in other tables are all combined so it's definitely a great idea to go to "Configuration" in SB and then in AO\RO, print out the various tables and edit them to give them some consistency before the conversion is run.

That's the quick and dirty - You may be in a more complex situation but this is the general rule for conversion\integration of AO\RO & SB with regard to table entries.

Hope that helps!

Tom Evans

[Elaine Tucker]

Tom, there is a little more information that is shared between the databases.

The address types and addresses & phone numbers will be "shared" between EE, RE & FE once you syncronize the systems, so be sure that you have guidelines set up for address updates in ALL OFFICES and that they are all on board with that. Meaning that if you update an address in EE it will cascade over to FE & RE.

We are in the process of integrating/syncronizing our EE, RE & FE; and have started with cleanup in EE since it is the database that feeds to all the other databases it needs to be in tip top shape.

Thanks,
Elaine

Quote:

Originally Posted by Tom Evans

Jane,

...

The overall picture is that in 7, AO\RO and SB share the same database and RE keeps one to itself - there is still fairly seamless transfer of graduated students to RE as new constituent records. Basically the only table that HAS to be synchronized (as far as I have seen) is the “Grade level Now” table between SB and AO\RO. Entries in other tables are all combined so it's definitely a great idea to go to "Configuration" in SB and then in AO\RO, print out the various tables and edit them to give them some consistency before the conversion is run.

That's the quick and dirty - You may be in a more complex situation but this is the general rule for conversion\integration of AO\RO & SB with regard to table entries.

Hope that helps!

Tom Evans

[Tom Evans]

Quote:

Originally Posted by Elaine Tucker

Tom, there is a little more information that is shared between the databases.

The address types and addresses & phone numbers will be "shared" between EE, RE & FE once you syncronize the systems, so be sure that you have guidelines set up for address updates in ALL OFFICES and that they are all on board with that. Meaning that if you update an address in EE it will cascade over to FE & RE.

We are in the process of integrating/syncronizing our EE, RE & FE; and have started with cleanup in EE since it is the database that feeds to all the other databases it needs to be in tip top shape.

Thanks,
Elaine

You are absolutely correct Elaine - The address and phone data for students and relations (and types for each which are tables), along with the table entries other than "Grade level Now" will all combine causing potential duplicate address\phone information and combined (potentially redundant) table entries. I was just pointing out that the "Grade level Now" table seems to be the only table that is required to be synchronized before running the integration.

Cleaning up the EE database first is absolutely the best way to go - as you point out, that is where all the data is initially captured into the system. The cleanup of the duplicate address and phone (and types) information (as well as the other combined table entries) can be done before the integration or after but it is definitely desirable to do it before hand if possible.

Tom

[Elaine Tucker]

ah... REQUIRED before sync-ing.... got it now!

Thanks for that clarification