I'm not adding subtitles -_-
For more infomation >> London Districts: Lee (Tour guide) - Duration: 4:03. 
For more infomation >> Porto Travel Guide - Duration: 9:17. 
Hello & Welcome, everyone!
Thank you for joining us for today's webinar, hosted by the LimsForum.
My name is Dinah Ramirez and I'm your Moderator for today's webinar.
Today's Webinar, "A Guide for Laboratory Systems Management
is PART 5 of a webinar series that's been presented by Joe Liscouski!
Today we'll be focusing on Supporting Laboratory Systems!
If you're joining us for the first time in the series,
Joe is an experienced laboratory automation/computing professional
with over forty years experience in the field,
including the design and development of automation systems,
LIMS, robotics and data interchange standards,
and consults on the use of computing in lab work.
He currently works with companies to establish planning programs for lab systems;
develop effective support groups;
and helps people with the application of automation & information technologies
in research and quality control environments.
We're excited to have Joe with us here again for Part 5 in his series,
so let's check-in with Joe and we'll get started!
Alright, Joe, thanks for joining us today! The floor is yours.
Thanks and welcome to the fifth session in this series.
We'll be looking at the support requirements for laboratory informatics.
That includes the roles of lab personnel, IT support, and vendor relationships.
As we've noted in these webinars, this companion book will provide useful background information
on the technologies, support, and other factors that can impact your ability to effectively
use these systems.
It should prove to be a useful reference as the webinars get into more technical details.
Much of the material in this session is expanded on in chapter 2 of the book.
The previous sessions have introduced the major systems in laboratory informatics and
looked at how the return on investment can be measured and evaluated.
In the last session, webinar 4, we extended the considerations for choosing between LIMS,
ELN, and SDMS for a single lab, and the potential for the same technology being used in multiple
labs, in a variety of configurations, including SaaS and remote servers.
During that session we began to see the need and potential roles for information technology support.
This session will cover that topic in more detail.
Once upon a time, when people first began to drive cars and trucks, they had to be able
to drive them and navigate their way around, they also had to be able to repair them if
something went wrong.
There weren't any road services, even if you had a means of calling them.
Eventually, people recognized the commercial benefits of automobile repair, and service
stations developed.
Over time cars changed to become attractive to a wider range of people, easier to drive
with more features that drivers and passengers wanted.
Along with that automotive services grew and met the need to support the increasing mechanical
sophistication of the cars that were produced.
Today, service groups have to deal with the basics of automotive maintenance, but also
be able to deal with specialized systems, many requiring additional specialized education.
In the early days of laboratory computing and experimental work, it was very rare to
find a turnkey computer that supported an experimental setup.
The scientist, in addition to doing science, was the systems designer, manager, and programmer.
Just like the early automobile drivers, the scientist had run the equipment and be his
own support.
For most labs using computers, the system consisted of a computer, the experimental
equipment, and either home grown or 3rd party software that scientists had to configure
or modify to meet their needs.
Any equipment used in the experiment would be supported by the vendor, but their support
was limited to what they provided and not how it worked with other components.
The overall success of the system depended on the user, the scientist.
Just like automobile manufactures in the early days of driving, instrument vendors realized
that if they want to people to buy their instruments they had to make them attractive, and that
meant easier to use and support with improved productivity gains through the use of computer
systems.
And just like automobile repair shops who were faced with systems that required added
training, or were simply beyond their capabilities, laboratory users found that their IT staff
often didn't have the backgrounds needed to meet their support needs.
They could handle basic maintenance, but didn't have the education to diagnose overall system issues.
The instrument system vendor would support their equipment, but when an experiment moved
into the coordination of multiple components, the users had to do a lot of the trouble-shooting themselves.
When we combine instruments, science, and computer systems, there are several areas
where it would be difficult to diagnose problems and figure out what needs attention.
The issue becomes even cloudier when the problems are viewed as "something just doesn't seem right."
As we move toward automated procedures that might feed into centralized database
things become even more complex.
We are outrunning basic systems support.
We looked at this slide in the last webinar.
The point was to contrast the typical corporate IT expectations with the needs of laboratory work.
One is more structured, the other has diverse needs and has their computers connecting to
equipment that is beyond the experience of most IT people.
We are looking at two different groups, both consisting of educated professionals, that
have different sets of experiences, needs, and expectations.
If those elements aren't discussed and rationalized, we have conflicting points of view, based
to an extent on a lack of appreciation for those differing requirements.
The lab is looking to get their work done using whatever tools are needed, and those
tools are diverse, depending on a range of scientific and computing technologies.
IT groups are looking at the stability of a large number of systems
and a complex networked infrastructure.
When many of us first began considering scientific computing in support of laboratory work, we
focused on the top four bullets on the right.
As lab data and information began to be available in digital formats, we saw the integration
of those elements into the corporate information pool.
In some cases it was the use of quality control results to provide more timely input into
production and solving product quality issues.
Researchers began to take advantage of it in large scale modeling and statistical analysis
applications – and we saw the arrival of Big Data applications.
All of this put more importance on streamlining lab processes and moving data and information
into places where people could take advantage of it.
Laboratory and senior management need to come to grips with the idea that laboratory systems
are not just a collection of isolated / independent components.
To be done well, they need as much planning and support as any manufacturing production line;
Would your company allow its production to be implemented as a series of independent
steps or do they want a smoothly functioning integrated operation?
To do that we need people that can carry out the items noted on the screen.
The labs dependence upon manual methods are giving way to facilities that carry out their work smoothly,
with high productivity levels and return on investment.
That usually means automation implemented where appropriate, with the support staff equal to the job.
What we need are people that are educated specifically for
Laboratory Technology Management & Planning.
This is more than an IT function as it embraces the full gamut of laboratory systems, their
interactions, and interdependencies.
These people would have to work with IT groups cooperatively and be responsible for resolving
conflicts in policies.
During the rest of this session we're going to look at the points noted on the screen.
The basic premise is one that has been noted earlier in this series: our ability to effectively
use laboratory systems is going depend upon having qualified people to plan and implement them.
We have to put the idea of implementing lab technologies on a case by case basis behind
us and look at lab operations as a whole.
How are we going to meet the labs needs?
You may want to start with manual methods of carrying out lab procedures, but will a
growing need for more testing and experimental work cause you to look for forms of automation
to keep up with the demand and have you look for more integrated approaches?
The items on the screen represent the major groupings of responsibilities that we are
going to be looking at.
The purpose of these professionals is to bridge the gap in subject matter expertise between
lab and IT personnel.
From an IT perspective it could be viewed as a specialization within their organization.
From the lab side, it would represent a source of expertise that would help them plan and
implement systems they need in their work.
These professionals are going to need excellent inter-personal skills.
They will need to be able to listen to people's issues without pre-judging them, provide clear
communications and be able to resolve conflicts as they occur.
Doing that will require that they have access to senior management to deal with conflicts
on policy issues; they can recommend solutions but it isn't likely that they will have
the authority to enact them.
This is a place for people with experience in change management; their existence in a
group foreshadows change and will raise anxiety levels, so clear communications and the ability
put people at ease will be important.
Of the items in the previous slide, this is one set of capabilities that are difficult to teach.
People can take courses in team building, conflict management, and so on, but realistically,
success in these skills is going to depend on maturity, experience, and personality.
This map is deceptively simple.
The material under "Lab Bench & Departmental" technologies includes what we've been talking
about in the previous four sessions and those that will follow.
The items I want to stress here are the software / hardware issues and there is one point that needs to
be made.
The LAE's are not a replacement for corporate IT departments, in fact they may be a specialize
element of those groups depending on how a company organizes itself.
Their role with regard to computing and networking hardware and software is to support IT policies
unless they conflict with lab operations; in those cases they are responsible for identifying
conflicts and recommend resolutions.
Among those conflicts are cases where an operating system upgrade might prevent applications
software from working properly or at all.
The application's vendor may not have completed software certification, testing or modifications
to be supportable under a new OS version, and the upgrade would prevent people in the
lab from getting their work done.
They would have a responsibility to evaluate a vendor's ability to keep up with operating
system software development as part of the product selection process.
The ideas behind product upgrades, retirement, and replacement needs a bit more discussion
to help flesh out the LAE's responsibilities.
This is a diagram that I find more useful from the user's point of view.
For more details on the entire diagram please check the reference noted on the slide.
Among the phases that products undergo in their development, the most critical for this
discussion are when products and technology reaches a level of maturity shown by the high,
medium and low impact points.
If the product is viable, a new version will be created with added features and capabilities
to make it more attractive and competitive.
A decision may also be made to completely redesign the product if the underlying technology
is dated or to take advantage of new options.
The decision to terminate the product could be made if it is no longer marketable.
Due to the rapid changes in technology, product life cycle phases are occurring at an increasing
pace.
You may pass through several product life cycles and product changeovers during the
useful life span of the data in your lab, which could be decades in biotech and pharmaceutical
industries.
How many product versions will your lab cycle through?
The possibilities of product termination, or significant upgrades are a concern in technology
management.
Well-planned, well-designed systems can tolerate change, inadequate planning can put you up
against a wall.
The same issues can occur when an entirely new product or technology is introduced, replacing
products that are already in service in your lab.
Planning against a vendor's product life cycle is a matter of balancing the benefits
of new product technologies against the potential for painting yourself into a corner.
The choices you or your predecessors make can limit your future options.
These are some of the issues that an LAE needs to keep in mind so that your lab isn't blindsided
by changes in vendor's development programs.
Your laboratory is going to be spending a lot of resources implementing systems to make
it work effectively.
If products they depend upon are slated for retirement or significant upgrade, those systems
may either continue using out of date components, that the vendor may no longer support, or
have to spend more resources modifying processes to accommodate replacement parts.
The more warning you have about changes the better you will be to handle them.
That lead time may give you the time you need to lobby the vendor to ensure compatibility
with older systems.
These considerations are nothing new, they are points that should be addressed during
the "vendor audit" phase of the validation process.
This received a lot of attention 20 years ago, but I don't know how seriously people
are taking it now.
The bottom line is simply this: you are going to be spending a lot of resources on developing
systems to support your lab's operations, if there are critical components, you need
to ensure that they are from reliable vendors with a track record of supporting their products
and working with their customers.
You might look at this topic and say "we've been through product changeovers before".
True, but in the past a lot of these changes occurred when people were using the equipment
and could adapt to change.
When we are looking at automated equipment it's a different story.
Adaptation may mean reprogramming systems.
Outsourcing is often used to expand the labs capabilities for both specialized testing
that is needed on an occasional basis or to handle overflow work.
The LAE's role in outsourcing is to help ensure that the results of the work can be
used within the laboratory's systems.
What form will the returned results take?
Are those results and that format compatible with your systems?
Can it be automatically entered or does it have to
re-formatted to work well?
Do they have good control over their systems including backup and archiving?
Again, it is a matter of qualifying your vendors and
and it is something an LAE would be expected to help with.
We've looked at these issues in the previous sessions.
The LAE's role is to cover a lot of the responsibilities that were directed to corporate
IT support.
The LAE's knowledge of lab operations will help ensure that the labs critical requirements
are given the consideration they need.
I've been referring to the professionals that would do laboratory technology management
and planning as Laboratory Automation Engineers, the title fits the work.
They are working as engineers that help design, implement, manage and support lab systems
that fulfill an automation function.
The "automation" aspect results from the optimization of laboratory processes through
a variety of technologies that include instrumentation, robotics, and data systems.
Who might they report to, and where do you find them?
The relationship between LAE's and corporate IT groups are a lot like that of professional
kitchen designer/installers and people who build homes.
The construction crews are there to create the structure, divide it into spaces and provide
the needed infrastructure.
When it comes to the space designated at a "kitchen", what you have is an empty space
with some parts of use-specific infrastructure elements: plumbing and power, floors, walls,
and ceiling.
The role of the kitchen designer/installer is customize that space so that it can function
as a working kitchen.
If there is a structural problem, the general contractor resolves it.
The role of the LAE is to build on top of the corporate informatics infrastructure and
adapt it to the needs of laboratory work.
In large organizations, the LAE may be part of a team.
In smaller ones, they are the team.
From a technology standpoint, the LAE's needs to understand science, laboratory, technologies,
and the computing infrastructure components.
They need to be strongest in Laboratory Technologies and their application to lab work, good in
the sciences, and competent in computing and informatics.
The depth of knowledge in the last point will depend upon the organization they support
and the availability of in-house IT groups.
Much of what we've talked about so far in this webinar series including database systems,
networking, and hosting is common to computer science.
A science background is useful in these discussions to understand the differences between lab
systems requirements and similar applications in other fields.
However the need for a science background will become evident in the next webinar as
we move in to supporting laboratory experiments.
The best source of these people are those with formal education and experience in science.
They would be able to relate to the application of the technologies and appreciate the subtleties
of the work.
It would be easier to educate a scientist in computing and informatics, than taking
a IT person and bring them up to speed on the scientific applications of computing.
There is also an interpersonal dimension to this, scientists will be more comfortable
talking with someone who has been in scientific work; communications is an important aspect
of the work.
The placement of LAE's within an organizational structure will vary depending upon the size
of that organization.
Their work is neither wholly scientific nor is it wholly information technology; they
bridge both endeavors and may prove to be an annoyance in highly structured organization
charts – the infamous "dotted line relationships".
In startup organizations, the available resources may be focused almost entirely on getting
lab work done.
They have funding to prove themselves and demonstrate their viability as a business
entity.
As a result the bulk of their resources will be spent on the lab.
As we've discussed, the informatics part of lab work needs considerable attention and
because of the need to prove themselves, anything that doesn't contribute directly to their
success is questionable overhead.
An LAE could be a significant contributor to their work and it would be reasonable to
have the LAE be the IT department.
Vendor supported SaaS informatics would relieve a lot of the traditional IT burden and allow
them to concentrate on systems that support lab work.
Office systems and infrastructure at this stage would require little active support
as long as the equipment, both hardware and software, came from reliable vendors and was
familiar to those working there.
If the organization chooses to outsource it's IT support, they should evaluate that organizations
ability to meet the criteria noted in the previous slides.
In large scientific organizations, the LAE's would be part of the corporate IT organization,
and take a good part of that budget.
The rest of the IT operations would support administrative operations as well as non-lab
research including any "Big Data" applications.
Having the LAE's as part of the corporate IT group would keep them in closer contact
to avoid problems developing over policy issues and data/information integration with database
systems that are outside the laboratory.
The LAE's primary efforts would be to support the labs.
In this structure, the laboratory and scientific work should be the dominant force in the organization
and it isn't likely that the LAE's efforts would be diverted, perhaps shifted to other
projects because of deadline pressures.
Other organizational structures may not behave in the same way.
You have to love corporate politics.
In manufacturing/production organizations, the LAE's would be, at best, part of the
corporate IT organization, and even there possibly as a part-time effort or completely
outsourced.
In this situation the lab's management is going to have make sure any user requirements
are developed with strong positions and justifications for it's needs to help ensure that needed
systems are put in place, when they are needed, and with the necessary functionality.
There are two issues that can impact the resources devoted to lab work.
First, there is the changing nature of lab operations.
Expenditures on lab operations are being looked at from a cost standpoint, so the ROI has
to be evaluated.
As part of that, testing that may have been manually performed may be moved to in-line
testing changing the nature of lab work.
Second, as noted in the last webinar, organizations will install enterprise resources planning
systems to integrate the computing and data needs of different parts of an organization
under one software platform.
With that, life can get very interesting.
Companies will often use ERP systems to manage their business operations out of one product
platform.
That provides a higher level of efficiency and integration.
These systems are expensive and have a learning curve that takes time and resources to manage.
The IT group may have justified the purchase with the idea that this will be the basis
of all the company's database needs.
And then the lab raises its hand with "we need a database system"…
IT's response may be "we can create one using the ERP systems as a base."
Do you build, buy, or rent a solution?
Using an ERP system as a base may seem attractive as some facets of lab operations, particularly
LIMS, are similar to other business practices.
One aspect of lab informatics that separates itself from business practices is the need
for connections to instrument-data systems.
Before you get into these discussions, you should have a solid set of user-requirements
documents, with critical functionality identified and justified, to provide a basis of discussion.
In most cases this is a deal breaker for ERP integration.
Once that is realized the "do you really need that?"
discussion begins.
That is up to you to justify.
The next step in that logic might be "we'll do all the non-instrument data system work
first, and then get to that last".
The problem with that argument is that the instrument data-system requirements may significantly
impact the design of the overall system, and if not addressed early in the process, any
changes needed to accommodate that functionality would completely blow the schedule and budget.
Corporate pressure for other projects may leave it in a software development limbo.
For most companies, buy or rent is the better choice, and by "rent" I'm referring
to the SaaS model.
The details for this choice are on the screen.
What it basically comes down to is that you have access to a proven product, with support,
and a user community to work with to get needed functionality incorporated into the product
and to help solve common problems.
It also means you can get up and running faster than you could with the build choice.
How fast you can put the software into practice depends entirely on the preparation you've
done in understanding the technology, how it relates to your lab's work, the development
of user requirements, and keeping your lab appraised of available products.
If you haven't done any of that, you are looking at potentially a year or two's effort.
If that work has been done, you should be able to get up and running quickly, particularly
if the vendor has a SaaS option that can be moved later on into an on-premises system
if that becomes desirable.
The biggest issue you are likely to face is the choice between configured and customizable
systems as shown on the left.
If you can, configured systems are the best option.
You don't want to find yourself in a situation where you've spend a lot of resources developing
software only to have to do it all over again when the next release of that software becomes
available.
Considering the amount of effort that has gone into these systems, it isn't likely
that you will come up with a need that requires custom software development.
If you do find a unique need, contact the user community to see if others are having
similar issues and perhaps as a group, pressure the vendor to make the changes.
Large organizations with a number of laboratories may be able to justify the development of
software to meet central database systems, a LIMS or ELN for example.
Spreading the cost over a number of labs may be something they can justify, but there are some issues.
Can the labs come to an agreement on a basic set of requirements, or a least a foundation
that individual labs can build upon?
The more labs you get into the mix the lower the likelihood of that being successful, particularly
if they aren't well versed in the technologies.
The end result if a project is successful is having a vendor with only one corporate
customer, with multiple installations needing support.
That support will be needed forever.
As will the requests for bug fixes and improvements.
IT will have to develop its own support staff, and be able to train them – there won't
be any outside source of expertise, no one else has access to the software.
While this organization is going to be running it's project, so will commercial vendors,
but they will be adding new functionality to their existing systems.
Is the IT group up to the work required, and do they have the level of demonstrated expertise
and capability for large projects?
What is the likelihood of the team being kept in place and not have people siphoned off
for other projects?
And finally, what are you going to work with while the development project is underway?
How will the accumulated data and information be integrated into the final systems?
During the session we've covered a lot of ground around the lab systems support issue.
One point that was noted earlier in this session is that much of what has been covered doesn't
require much education beyond a high level of competence in computer systems and an understanding
of modern database technology to support lab operations.
This is going to change significantly in the next webinar as we move toward the generation of laboratory
data and information through instrument data systems and sample preparation.
There the weight of the scientific work will be helped. And that session is scheduled for May 24th.
Are there any questions?
Okay thank you, Joe! I don't see any questions at this point in time but if anyone does have
any questions feel free to go ahead and submit those in the chat box or even if you have any comments
about what Joe discussed today feel free
to go ahead and share your thoughts with
us. I'd like to remind everyone that I
have this webinar recorded so once it is
available we will go ahead and notify
everyone who is registered that the
recording is available and it will be
added to the existing series recordings
and I went ahead and I provided a link
to that series in the chat box so you
can go ahead and refer back to it and
that's where that recording will be
housed once it's available. Ok, so while
we wait for any questions that might
come up we did have a few questions that
came up before today's session so I will
go ahead and pose those questions here
to Joe. We will be sending out a link to
these slides as well. I see that that
question is coming in, so those slides
will be added to the existing series
recordings page and it will also be sent
out at that point in time.
Ok, so Joe, let's go ahead and address
the questions that came in before the
webinar. "What are the two most
important issues in laboratory systems?"
From my perspective it's education and
planning. We've either move past the
phase of buying systems to solve
individual problems or assume do that.
Labs waste a lot of time moving data
information between systems manually
that ties up people and it means that
the lab will never move beyond a certain
plateau in productivity.
Lab personnel need to understand what
technologies are available to them; how
they can be integrated into their
workflows; and how they connect to other
systems; and that's the education part.
Planning takes that understanding and
how things are going to work in both the
short term and long term. Plus the
ability to deal with change both
technologically and handling change managment
for people as well.
Ok, great, thank you for answering that
question that came in. Again I'm not
saying any more questions in the chat
box but I do have two more that came in
before for the webinar. Another question
that came in asks "Why can't we just use
our IT people to troubleshoot our
systems?" Well they can if the problem can
be easily isolated to a computer system
or application. But, getting to that
point is the problem I've dealt with cases
where the symptom of a problem was
simply a lot of noise in the instrument
signal. The evidence for the problem was
a chromatographic report with way
too many peaks in it. It wasn't a
software problem, but rather a loose
ground wire connecting it to the outlet.
The problem is going from the symptom of
the solution and that to what the
real problem is and that requires
understanding the process, the equipment,
what contributing issues there are
and the trial and error of problem
solving. Frequently you'll find that
either IT people will go "well, let's see...
we can understand the hardware, we can
understand the software...but this other
stuff out there? We have no clues
what that is. And sometimes disparate
vendors will be very good at managing
their instruments but when it comes to
the computer systems, they're not that
on top of all that stuff.
Ok, thank you for addressing that as
well. The last question that came in asks
"What are the issues with getting
management to support a lab automation
engineering position?" Probably the
biggest one is having them understand
the value of a specialized role. The
position represents cost and they
need to see in the potential return. A
lot of that can come from avoiding bad
purchases, faster problem resolution
which means less downtime in the lab,
having access to people can be effective
at planning and implementing systems
that will work really work and be
supportable. Doing that work means
bridging the gap between IT and lab work
and that can be hard to define until a
critical problem occurs. I've seen
systems put in by people where that have
worked very well until the first upgrade
is done and then they crash and they don't
work anymore because they weren't
designed and built or
engineered with the idea of upgrades
being supported. So it's a matter of "gee,
we don't know we need them until you
have a problem that can't be solved any
other way." Ok, thank you for
addressing that as well Joe. It does
look like you're getting a comment here.
Ok, so "When an organization has many
global labs, do you suggest an LAE in each
location or a centralized team or a
hybrid?" Well, I'm not sure what you mean
by a hybrid but I think each
organization, each site is gonna need its
own personnel just to get a timely
response, but I think what you need to do
if you really have a global lab is have
an organization put together where you
have local support for the LAEs
and then have them periodically get
together so that people understand
what's going on at different sites where
there might be common problems common
solutions to those problems and so the
coordination can get done properly.
Having everybody operate independently
sometimes works a
little bit but as soon as you start
dealing with coordination issues or
people recognizing they have the same
problems in multiple places that need to
be solved then the isolated issue
becomes a problem, so it's better
having people on-site so they can
give a timely response to problems but
also have them coordinate with other
people in different parts of the
organization so that solutions can be
passed around. Ok, I hope that answers
your question Jamison, Ok, great I think
it did. It appears that we may be getting
another question or maybe comment so
we'll take take another second or here
and just wait to see if something comes
up. Okay there it is..."What strategies can
you suggest when corporate IT policies
and decision making interfere with the
operation of the lab? For example
non-standard operating systems or
computers that prompts IT to boot off
the network." Yeah that's pretty much the
typical problem. Lab systems are diverse
they're not window usually not
windows-based or not always
windows-based. You'll find UNIX and other
operating systems out there. The problem
is to start at the
point of purchase. Make sure people
understand what's going on, make sure
IT knows what you're purchasing and what
the support strategies are. But the most
the most important thing is keeping the
lab operations going. So as I pointed
out a few slides ago,
if corporate policy is that
everybody is operating system be
upgraded at the same level and that
upgrade causes the laboratories computer
to crash or the application not to work
then they've got to make a pretty quick
quick decision on what their priorities
are and having everybody be at the same
operating system level is not exactly a
good priority. First thing, the main thing,
you got to do is to keep the labs
running and that happens frequently
particularly when you're dealing with
small vendors.
So this the primary strategy is
communications. Letting people understand
what the priorities are, what your
support strategies are, making sure the
vendors are going to be providing timely
support as needed.
An upgrade has to be
delayed. Let people know soon enough
so they can incorporate that in their
plans. Some great tips there! Scott, I
hope that answers your question. We'll
just wait another second here to see if
anything else comes through. Okay looks
like it does.. as we wait for maybe
those questions to come through, we do
have a registration date set for the
next webinar of course. We will be
sending that registration out once it is
available so if you are interested stay
tuned for that! I know that we'll be
communicating more information about the
next webinar in the LiMSforum
newsletter as well sending out a
separate email to anyone who's attended
here today as well as may be registered
for maybe past series so we will notify
you in that way or you'll see it in
those newsletter communications. So you
will see those shortly. I know a few
people have commented that they're
interested in attending the next session.
If anyone has problems or has
questions about support issues and needs
help with support issues and they don't
want to address them now, my email
address is on the slide so you can
contact me whenever it's convenient for
you.
Ok, so "there are so many small vendors
out there yeah that are not keeping up
with updates and patching." That's a bit
of a problem! The issue, probably the
simplest issue, is as soon as data is
generated by those systems, move it to a
another system where the data can
be managed better. Small
vendors are a bit of a problem.
I ran into a Pittsburgh conference
a couple years ago who was really
excited about his instrument and the
things that could do and when I asked
him about his software system he said
well we have software it's there, we
don't pay a lot of attention to it
because we're primarily working on the
instrument and the software is the
interface to the instrument; it's also
where you get all your data. So
basically, if they're having problems
with your vendor, you're with the kind of
issue that's on the screen, move your
data from that system as soon as you
can once it's processed and that will
help maintain the integrity
of the data but first you have to make
sure that all the results have been
generated that they've been checked and
verified and then move it off that
system on to another one.
Another issue along those lines is user
communities. Find out how many other
other customers that vendor has and
put together a user
group to help deal with the problem or
else pressure the vendor as a group to
make sure things start getting done in a
more timely basis. Okay great that is a
good tip - and good idea. Yes, thank you.
I think that answers their
question there. Okay well I don't think
there are any other questions coming
through. We could probably go ahead and
close out today's session like I said
this is being recorded and we will send
out a link to the recording once it's
available. It will also be available on
the LiMSforum along with the other
webinar recordings for this series.
If you need to contact Joe with and any
additional questions, concerns, or topic
ideas for future webinars feel free to
go ahead and email him. He's more than
happy to go ahead and just address those
for you. Thank you Joe and everyone for
attending today's webinar! And if you
have any questions for me about today's
webinar session please let me know.
Thank you all for joining! Thank you,
thank you so much and thank you again
Joe! You're welcome! Take it easy.
Đăng ký:
Đăng Nhận xét (Atom)
Không có nhận xét nào:
Đăng nhận xét